步骤1：

Question

我设置了一个包含三个成员的副本集，其中一个是仲裁者。

有一次我重新启动一个成员，成员保持RECOVERING很长一段时间并且不再是SECONDARY，即使数据库不是很大。

副本集的状态如下：

rs:PRIMARY> rs.status()
{
        "set" : "rs",
        "date" : ISODate("2013-01-17T02:08:57Z"),
        "myState" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "name" : "192.168.1.52:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 67968,
                        "optime" : Timestamp(1358388479000, 1),
                        "optimeDate" : ISODate("2013-01-17T02:07:59Z"),
                        "self" : true
                },
                {
                        "_id" : 2,
                        "name" : "192.168.1.50:29017",
                        "health" : 1,
                        "state" : 7,
                        "stateStr" : "ARBITER",
                        "uptime" : 107,
                        "lastHeartbeat" : ISODate("2013-01-17T02:08:56Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 3,
                        "name" : "192.168.1.50:27017",
                        "health" : 1,
                        "state" : 3,
                        "stateStr" : "RECOVERING",
                        "uptime" : 58,
                        "optime" : Timestamp(1358246732000, 100),
                        "optimeDate" : ISODate("2013-01-15T10:45:32Z"),
                        "lastHeartbeat" : ISODate("2013-01-17T02:08:55Z"),
                        "pingMs" : 0,
                        "errmsg" : "still syncing, not yet to minValid optime 50f6472f:5d"
                }
        ],
        "ok" : 1
}

我该如何解决这个问题？

Answer 1

我遇到了完全相同的问题：副本的辅助成员卡在恢复模式中。这里如何解决问题：

停止辅助mongo db
删除所有辅助数据库数据文件
启动secondary mongo

它将以startup2模式启动，并将复制来自Primary

Answer 2

我已按照以下程序解决了问题。

步骤1：

登录到其他节点并从mongodb replicaset中删除问题节点。例如。

rs.remove("10.x.x.x:27017")

第2步：

停止问题节点上的mongodb服务器 systemctl stop mongodb.service

第3步：

在dbpath上创建一个新的新文件夹 mkdir /opt/mongodb/data/db1 注意：现有路径为/ opt / mongodb / data / db

第4步：

修改/etc/mongod.conf或mongdb yaml文件中的dbpath dbPath: /opt/mongodb/data/db1

第5步：

启动mongodb服务 systemctl start mongodb.service

第6步：

取回现有文件夹并将其删除

mkdir /opt/mongodb/data/backup mv /opt/mongodb/data/db/* /opt/mongodb/data/backup tar -cvf /opt/mongodb/data/backup.tar.gz /opt/mongodb/data/backup rm -rf /opt/mongodb/data/db/

Answer 3

方法1。
1. 停止第一个中学
2. 删除其dbpath的内容
3. 重新启动辅助
4. 等待它赶上主要
5. 重复第二次中学的过程
方法2（更安全）
1. 删除两个辅助数据库上dbpath的内容
2. 将dbpath的内容复制到两个辅助数据库的dbpath
3. 启动旧的主数据库。
4. 启动其中一个旧中学。
5. 等待，直到选择新的主要数据库。
6. 启动其余的辅助服务器。

Answer 4

如果复制已经中断了一段时间，并且在从属设备上没有足够的数据来恢复复制，就会发生这种情况。

您必须通过从头开始复制数据或从另一台服务器复制数据然后恢复数据来re-sync the slave。

Answer 5

检查此问题的{mongodb文档https://docs.mongodb.com/manual/tutorial/resync-replica-set-member/#replica-set-auto-resync-stale-member

为什么mongodb的成员会继续进行RECOVERING？

5 个答案:

步骤1：

第2步：

第3步：

第4步：

第5步：

第6步：