4

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

有一次我重新启动一个成员,这个成员保持了很长一段时间的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
}

我应该如何解决这个问题?

4

4 回答 4

6

我有完全相同的问题:副本的次要成员陷入恢复模式。这里如何解决这个问题:

  1. 停止辅助 mongo db
  2. 删除所有辅助数据库数据文件
  3. 启动二级mongo

它将以 startup2 模式启动,并将复制来自 Primary 的所有数据

于 2015-03-11T11:21:24.180 回答
3

我已经按照以下步骤解决了这个问题。

步骤1:

登录到不同的节点并从 mongodb 副本集中删除问题节点。例如。

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/

于 2018-04-17T11:20:47.453 回答
1

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

您必须通过从头开始复制数据或从另一台服务器复制数据然后恢复它来重新同步从属服务器。

于 2016-04-15T21:10:30.087 回答
-1

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

于 2017-01-31T16:00:56.487 回答