最近、レプリカ セットのメンバーが数日間同期しなくなりました。「非常に古いレプリカ セット メンバーの再同期」の手順に従って、セカンダリマシンで停止mongod
し、データ ディレクトリを消去してプロセスを再開し、マシンをプライマリに再同期させました。
すべてが完璧に機能したか、そう見えました。ロギングは、同期がうまくいったことを示しました。最終的に、それは完了として表示さrs.status()
れ、セカンダリ マシンで次の出力が得られました。
# The secondary machine's status for itself and its primary:
{
"_id" : 0,
"name" : "myprimary:myport",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 497,
"optime" : {
"t" : 1347562257000,
"i" : 1
},
"optimeDate" : ISODate("2012-09-13T18:50:57Z"),
"lastHeartbeat" : ISODate("2012-09-13T19:00:34Z"),
"pingMs" : 3
},
{
"_id" : 2,
"name" : "mysecondary:myport",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"optime" : {
"t" : 1347562257000,
"i" : 1
},
"optimeDate" : ISODate("2012-09-13T18:50:57Z"),
"self" : true
}
予想どおり、マシンは同期しており、最適時間の値を共有しています。しかし、プライマリ マシンは別の話です。再同期が完了してからプライマリの optime が進んだにもかかわらず、非同期のセカンダリがまだ表示されます。
# The primary machine's status for itself and its secondary:
{
"_id" : 0,
"name" : "myprimary:myport",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 497,
"optime" : {
"t" : 1347562257000,
"i" : 1
},
"optimeDate" : ISODate("2012-09-13T18:50:57Z"),
"self" : true
},
{
"_id" : 2,
"name" : "mysecondary:myport",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"optime" : {
"t" : 1347103757000,
"i" : 1
},
"optimeDate" : ISODate("2012-09-08T11:29:17Z"),
"lastHeartbeat" : ISODate("2012-09-11T17:27:06Z"),
"pingMs" : 3
}
私は何が欠けていますか?最初は「待って」と思ったのですが、1時間近く経ち、データベースにはその間に挿入がありました。プライマリにセカンダリのハートビート チェックを強制することはできますか? それとも、再度同期する必要がありますか?
私がプライマリで見つけることができる唯一の本当の奇妙な点はこれです:
PRIMARY> use local;
PRIMARY> db.slaves.find()
{ "_id" : ObjectId("4f675b909d8e143a90055864"), "host" : "<hostIP>", "ns" : "local.oplog.rs", "syncedTo" : { "t" : 1347395837000, "i" : 1 } }
{ "_id" : ObjectId("50522761212b77e9637ad541"), "host" : "<hostIP>", "ns" : "local.oplog.rs", "syncedTo" : { "t" : 1347562257000, "i" : 1 } }
これらは同じホストです (問題のセカンダリ マシン)。私の理解では、これは 1 つのエントリを表示するはずですが、何を追跡し、どのように更新するかをよく理解せずに触れることをためらっています。