Question

我使用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的这些注意事项是无限的。根据{{1}}，在db.currentOp()（副本集的主要副本）上有一个长时间运行的查询日志，试图检索oplog。这些查询会降低server1的性能，因此我的数据库运行速度非常慢。

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

upd：我们的服务器每个都有64 GB的内存。它确实是虚拟机。

Answer 1

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

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

MongoDB复制超时

1 个答案: