MongoDB 复制超时答案

【问题标题】：MongoDB replication timeoutMongoDB 复制超时
【发布时间】：2017-06-28 09:25:43
【问题描述】：

我使用 MongoDB 3.4.3 并在一个副本集中拥有三台机器。将其命名为server1、server2 和server3。 server2 处于恒定回滚状态，因此我们将其关闭。 server3 处于恢复状态并尝试从 server1 获取 oplog，但其尝试导致 ExceededTimeLimit 异常。这是server3日志的摘录：

2017-06-26T14:42:14.442+0300 I REPL     [replication-0] could not find member to sync from
2017-06-26T14:42:24.443+0300 I REPL     [rsBackgroundSync] sync source candidate: server1:27017
2017-06-26T14:42:24.444+0300 I ASIO     [NetworkInterfaceASIO-RS-0] Connecting to server1:27017
2017-06-26T14:42:24.455+0300 I ASIO     [NetworkInterfaceASIO-RS-0] Successfully connected to server1:27017
2017-06-26T14:42:54.459+0300 I REPL     [replication-0] Blacklisting server1:27017 due to required optime fetcher error: 'ExceededTimeLimit: Operation timed out, request was RemoteCommand 191739 -- server1:27017 db:local expDate:2017-06-26T14:42:54.459+0300 cmd:{ find: "oplog.rs", oplogReplay: true, filter: { ts: { $gte: Timestamp 1497975676000|310, $lte: Timestamp 1497975676000|310 } } }' for 10s until: 2017-06-26T14:43:04.459+0300. required optime: { ts: Timestamp 1497975676000|310, t: 20 }

所以这些检索 oplog 的尝试是无限的。根据db.currentOp()，在server1（副本集的主节点）上有一个长时间运行的查询日志，试图检索oplog。这些查询降低了server1 的性能，因此我的数据库运行非常缓慢。

当前server1 的 oplog 大小为 643 GB。我认为它的大小是复制不起作用的原因。 server2 也有 oplog 超时问题，所以我们暂时关闭了它。这种情况已经持续了一个多星期。我在主机上有超过 5 TB 的数据。如何恢复副本集？

更新：我们的服务器每台都有 64 GB 的内存。确实是虚拟机。

【问题讨论】：

标签： mongodb mongodb-replica-set

【解决方案1】：

你可以休息一下吗？因为看起来您的机器（server1）没有足够的内存。有 5TB 的数据和这么大的 opLog，需要的内存量是数百 GB。我不会尝试将该系统作为一个副本集运行。更像是 3-5 个分片集群（总共 9-15 个节点；每个分片 3 个副本集）。好的规则是将节点大小始终保持在 2TB 以下，如果可以存档的话，1TB 是一个很好的起点。

如果您可以有停机时间，您应该将您的 opLog 缩小到更合理的大小。您可以从 50GB 开始。步骤可以找到here。

【讨论】：

我们的服务器每台都有 64 GB 的内存。确实是虚拟机。
我们有 10*1,1TB 集群。每个集群有 120GB 内存。我们用 64GB 进行“测试”，但性能不够好。