Mongo DB副本设置为停留在RECOVERING状态

我们已经创建了一个副本集，现在的问题是副本集的2个成员[3个成员集]从48小时开始处于恢复模式。最初，恢复节点的大小在增加，现在甚至停止了。因此，在恢复节点时，它们会在90 GB数据和60+ GB本地数据后卡住。

如何摆脱这种模式？

replication mongodb restore

— 阿维纳什·萨胡（Avinash Sahu）
source

Answers:

这有点不安全，因为不知道为什么次级服务器进入恢复状态。

如上所述，但是在此过程中停止您的应用程序。这样可以防止您的应用程序插入的数据多于辅助副本能够复制的数据。但是，在生产过程中可能会出现问题。

一些注意事项：

使用彩信。它是免费的，易于设置，并且为您提供有关副本集的良好信息。尝试将“复制滞后”的值保持在0左右，并采取一切必要措施，使复制滞后永远不会大于“复制操作日志窗口”。

始终确保您拥有1Gb网络和（抱歉）大量的RAM。越多越好。其他经验法则：RAM和SSD的一半而不是RAM的两倍，并且没有SSD（RAM保持在合理范围内）。

免责声明： 在修改生产数据之前，请务必对其进行备份。

— 马库斯·W·马尔伯格
source

截至目前，副本集中没有辅助节点。一个处于PRIMARY模式，另外两个处于RECOVERING模式。

— Avinash Sahu 2014年

那么，逻辑第二。过程是相同的。

— Markus W Mahlberg 2014年

我已经尝试过多次启动Mongo实例并重新同步，每次它开始将数据复制到其他节点直到固定大小（〜96gb），然后卡住。oplog大小是否与它有关？

— Avinash Sahu 2014年

并非如此，除了以下事实：当您插入的数据多于操作日志在初始重新同步期间可以容纳的数量时，重新同步可能会停止。在这种情况下，请选择选项2或3。

— Markus W Mahlberg 2014年

您能进一步解释一下吗？“而不是一半的RAM和SSD，而不是两倍的RAM和没有SSD（RAM保持在合理范围内）。”

— Stephen Nguyen

即使从辅助服务器上的新dbpath开始复制，复制过程也会失败。因此，要在操作日志中进行一些更改。必须将oplog的大小设置为最佳值，以便它应该能够处理对其进行的所有应用程序写入。

增加oplog大小：

关闭主服务器

use admin

db.shutdownServer()

以独立方式启动主服务器并在其他端口上运行，例如37017

在端口37017登录到mongo

mongo --port 37017

删除本地数据库中的旧内容

为了安全起见，请在丢弃前对旧oplog进行备份

mongodump --db local --collection 'oplog.rs' --port 37017

将旧内容删除到本地数据库中

use local

db.oplog.rs.drop()

db.me.drop()

db.replset.election.drop()

db.replset.minvalid.drop()

db.startup_log.drop()

无法删除replset集合，因此请使用必需的id将其删除：

db.system.replset.remove({ "_id" : "your_replsetname"})

创建所需大小（例如50 GB）的新操作日志

db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } )

您也可以在mongod.conf文件中以MB为单位指定操作日志大小，例如50 GB为429496 MB

replication:
   oplogSizeMB: 429496

希望这可以帮助！！！

编辑：

正如Nicholas Tolley Cottrell在评论中提到的那样。在MongoDB 3.6版中，我们可以在运行时更改操作日志大小，而无需重新启动。

检查当前操作日志大小

use local
db.oplog.rs.stats().maxSize

将操作日志大小更改为10 GB

db.adminCommand({replSetResizeOplog: 1, size: 10000})

— 杰瑞
source

以上是3.6版本的过时版本。现在，您可以调整操作日志的

— Nicholas Tolley Cottrell

@NicholasTolleyCottrell是的，我已经编辑了答案。

— 杰瑞