mongodb - 无尽的二次恢复状态

Question

我在 MongoDB 3.0.2 上构建了一个包含一个主节点、一个辅助节点和一个仲裁节点的复制集。主服务器和仲裁服务器位于同一主机上，辅助服务器位于另一台主机上。

随着写入过载的增加，从节点无法跟随主节点进入恢复状态。主服务器可以连接到辅助服务器，因为我可以通过主服务器主机上的 Mongo shell 登录到辅助服务器。

我停止所有操作，并使用命令 rs.status() 观察辅助节点的状态，然后键入命令 rs.syncFrom("primary's ip:port")在中学。

然后rs.status()命令的结果显示辅助设备的optimeDate远远落后于主设备，并且间歇性地出现一条消息，如下所示:

“设置”:“shard01”，
“日期”:ISODate(“2015-05-15T02:10:55.382Z”),
“我的州”:3，
“成员”:[
{
“_id”:0，
"名称": "xxx.xxx.xxx.xxx:xxx",
“健康”:1、
“状态”:1，
“stateStr”:“主要”，
“正常运行时间”:135364，
"optime": 时间戳(1431655856, 6),
"optimeDate": ISODate("2015-05-15T02:10:56Z"),
"lastHeartbeat": ISODate("2015-05-15T02:10:54.306Z"),
"lastHeartbeatRecv": ISODate("2015-05-15T02:10:53.634Z"),
“平女士”:0，
"选举时间": 时间戳(1431520398, 2),
"选举日期": ISODate("2015-05-13T12:33:18Z"),
“配置版本”:3
},
{
“_id”:1，
"名称": "xxx.xxx.xxx.xxx:xxx",
“健康”:1、
“状态”:7，
“stateStr”:“仲裁者”，
“正常运行时间”:135364，
"lastHeartbeat": ISODate("2015-05-15T02:10:53.919Z"),
“lastHeartbeatRecv”:ISODate(“2015-05-15T02:10:54.076Z”)，
“平女士”:0，
“配置版本”:3
},
{
“_id”:2，
"名称": "xxx.xxx.xxx.xxx:xxx",
“健康”:1、
“状态”:3，
"stateStr": "正在恢复",
“正常运行时间”:135510，
"optime": 时间戳(1431602631, 134),
"optimeDate": ISODate("2015-05-14T11:23:51Z"),
"infoMessage": "找不到要同步的成员",
“配置版本”:3，
“ self ”:真实
}
],
“好的”:1

"infoMessage" : "could not find member to sync from"

主节点和仲裁节点都正常。我想知道此消息的原因以及如何将辅助设备的状态从“恢复”更改为“辅助”。

Answer 1

问题(最有可能)

主节点的最后一次操作来自“2015-05-15T02:10:56Z”，而辅助节点的最后一次操作来自“2015-05-14T11:23:51Z”，这是一个相差大约15个小时。该窗口很可能超过您的复制 oplog 窗口(oplog 中第一个和最后一个操作条目的时间之间的差异)。简而言之，主服务器上的操作太多，辅助服务器无法跟上。

更详细一点(虽然简化):在初始同步期间，辅助同步的数据是给定时间点的数据。当该时间点的数据同步完毕后，辅助节点将连接到 oplog，并根据 oplog 条目应用该时间点与现在之间所做的更改。只要 oplog 保存上述时间点之间的所有操作，这种方法就很有效。但 oplog 的大小是有限的(即所谓的 capped collection )。因此，如果主服务器上发生的操作多于 oplog 在初始同步期间可以容纳的操作，则最旧的操作将“淡出”。辅助设备认识到并非所有操作都可用来“构造”与主设备相同的数据，因此拒绝完成同步，并保持在 RECOVERY 模式。

解决方案

该问题是一个已知问题，而不是一个错误，而是 MongoDB 内部工作原理以及开发团队做出的一些故障安全假设的结果。因此，有几种方法可以处理这种情况。遗憾的是，由于您只有两个数据承载节点，因此所有节点都涉及停机。

选项 1:增加 oplog 大小

这是我的首选方法，因为它可以一次性(某种程度上)解决所有问题。不过，它比其他解决方案要复杂一些。从高层次的角度来看，这些是您要采取的步骤。

1. 关闭主服务器
2. 使用直接访问数据文件的方式创建 oplog 的备份
3. 以独立模式重新启动 mongod
4. 将当前 oplog 复制到临时集合
5. 删除当前oplog
6. 重新创建具有所需大小的 oplog
7. 将 oplog 条目从临时集合复制回 Shiny 的新 oplog
8. 作为副本集的一部分重新启动 mongod

在进行初始同步之前，不要忘记增加辅助节点的 oplog，因为它可能在将来的某个时候成为主节点!

详情请阅读"Change the size of the oplog" in the tutorials regarding replica set maintenance .

选项 2:同步期间关闭应用

如果选项 1 不可行，唯一真正的其他解决方案是关闭导致副本集负载的应用程序，重新启动同步并等待其完成。根据要传输的数据量，以几个小时计算。

个人笔记

oplog 窗口问题是一个众所周知的问题。虽然使用 MongoDB 可以轻松设置副本集和分片集群，但需要相当多的知识和经验才能正确维护它们。在不了解基础知识的情况下，不要运行像具有复杂设置的数据库这样重要的东西 - 万一发生坏事(tm)，很可能会导致 FUBAR 的情况。