我设置了一个包含三个成员的副本集,其中一个是仲裁者。
有一次我重新启动一个成员,成员保持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
}
我该如何解决这个问题?
答案 0 :(得分:3)
我遇到了完全相同的问题:副本的辅助成员卡在恢复模式中。 这里如何解决问题:
它将以startup2模式启动,并将复制来自Primary
的所有数据答案 1 :(得分:1)
我已按照以下程序解决了问题。
登录到其他节点并从mongodb replicaset中删除问题节点。例如。
rs.remove("10.x.x.x:27017")
停止问题节点上的mongodb服务器
systemctl stop mongodb.service
在dbpath上创建一个新的新文件夹
mkdir /opt/mongodb/data/db1
注意:现有路径为/ opt / mongodb / data / db
修改/etc/mongod.conf或mongdb yaml文件中的dbpath
dbPath: /opt/mongodb/data/db1
启动mongodb服务
systemctl start mongodb.service
取回现有文件夹并将其删除
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/
答案 2 :(得分:1)
方法1。
方法2(更安全)
答案 3 :(得分:0)
如果复制已经中断了一段时间,并且在从属设备上没有足够的数据来恢复复制,就会发生这种情况。
您必须通过从头开始复制数据或从另一台服务器复制数据然后恢复数据来re-sync the slave。
答案 4 :(得分:-1)