3 つのノードを持つ MongoDB レプリカ セットを使用しています。データベースは 20 億以上のレコードを含む非常に大きなもので、ディスク (WiredTiger MongoDB エンジン) で 700 GB を占有します。ほとんどのドキュメントでは、挿入 (1 日あたり数百万件) が実行され、その後、読み取りと更新が行われます。
セカンダリ メンバーのディスクを交換した後、データ フォルダーが空になり、初期同期が開始されました。ログを見ると、レコードをコピーするのに約 7 時間、インデックスを作成するのに 30 時間かかりましたが、その間に挿入/更新されたすべてのレコードを oplog に含めるには長すぎました。
2016-11-16T23:32:03.503+0100 E REPL [rsBackgroundSync] too stale to catch up -- entering maintenance mode
2016-11-16T23:32:03.503+0100 I REPL [rsBackgroundSync] our last optime : (term: 46, timestamp: Nov 15 10:03:15:8c)
2016-11-16T23:32:03.503+0100 I REPL [rsBackgroundSync] oldest available is (term: 46, timestamp: Nov 15 17:37:57:30)
2016-11-16T23:32:03.503+0100 I REPL [rsBackgroundSync] See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember
最初にこのメンバーを再起動し、再同期を開始しました:
2016-11-16T23:47:22.974+0100 I REPL [rsSync] initial sync pending
2016-11-16T23:47:22.974+0100 I REPL [ReplicationExecutor] syncing from: x3:27017
2016-11-16T23:47:23.219+0100 I REPL [rsSync] initial sync drop all databases
2016-11-16T23:47:23.219+0100 I STORAGE [rsSync] dropAllDatabasesExceptLocal 5
2016-11-16T23:53:09.014+0100 I REPL [rsSync] initial sync clone all databases
データフォルダを見ると、すべてのファイルが消去され、ファイルが大きくなり始めていました。しかし、約 8 時間後、データベースの 5% がかろうじて再同期されました。
このような大規模な同期にはどのようなアプローチを使用しますか?
oplog のサイズを大きくしようと考えましたが、そうするとレプリカ セット全体のダウンタイムが必要になります。ダウンタイムなしで使用できるアプローチは何ですか?