我有一个副本集,我正在尝试将主服务器升级到具有更多内存和升级磁盘空间的主服务器。所以我在新主服务器上一起搜索了几个磁盘,从辅助服务器中同步数据并将其添加到副本集。在检查了rs.status()之后,我注意到所有辅助设备都在主要设备后面大约12个小时。因此,当我尝试将新服务器强制到主要位置时,它将无法工作,因为它不是最新的。
这似乎是一个大问题,因为如果主要失败,我们至少有12个小时,有些差不多48小时。
oplogs全部重叠,oplogsize相当大。我能想到的唯一一件事就是我在主服务器上执行了大量的写入/读取操作,这可能会使服务器处于锁定状态,从而无法正常赶上。
有没有办法可以强制辅助设备赶上主要设备?
目前有5台服务器,其中最后2台将替换其他2个节点。 _id为6的节点将是替换主节点的节点。离主要运行时间最远的节点落后48小时。
{
"set" : "gryffindor",
"date" : ISODate("2011-05-12T19:34:57Z"),
"myState" : 2,
"members" : [
{
"_id" : 1,
"name" : "10******:27018",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 20231,
"optime" : {
"t" : 1305057514000,
"i" : 31
},
"optimeDate" : ISODate("2011-05-10T19:58:34Z"),
"lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
},
{
"_id" : 2,
"name" : "10******:27018",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 20231,
"optime" : {
"t" : 1305056009000,
"i" : 400
},
"optimeDate" : ISODate("2011-05-10T19:33:29Z"),
"lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
},
{
"_id" : 3,
"name" : "10******:27018",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 20229,
"optime" : {
"t" : 1305228858000,
"i" : 422
},
"optimeDate" : ISODate("2011-05-12T19:34:18Z"),
"lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
},
{
"_id" : 5,
"name" : "10*******:27018",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 20231,
"optime" : {
"t" : 1305058009000,
"i" : 226
},
"optimeDate" : ISODate("2011-05-10T20:06:49Z"),
"lastHeartbeat" : ISODate("2011-05-12T19:34:56Z")
},
{
"_id" : 6,
"name" : "10*******:27018",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"optime" : {
"t" : 1305050495000,
"i" : 384
},
"optimeDate" : ISODate("2011-05-10T18:01:35Z"),
"self" : true
}
],
"ok" : 1
}
答案 0 :(得分:1)
我不确定为什么在您的情况下同步失败,但是强制重新同步的一种方法是删除副本上的数据文件并重新启动mongod。它将启动重新同步。见http://www.mongodb.org/display/DOCS/Halted+Replication。这可能需要相当长的时间,具体取决于数据库的大小。
答案 1 :(得分:0)
在查看完所有内容之后,我看到了一个错误,这导致我回到了在主服务器上运行的mapreduce,它有这个问题:https://jira.mongodb.org/browse/SERVER-2861。因此,当尝试复制时,由于oplog中的错误/损坏操作,它无法同步。