大規模データベース上のMongoDB初期同期

Question

3つのノードを持つMongoDBレプリカセットを使用しています。データベースは2億以上のレコードで、ディスク（WiredTiger MongoDBエンジン）で700GBを占めています。ほとんどの場合、文書には挿入物（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のサイズを増やすことを考えましたが、それはレプリカセット全体のダウンタイムを必要とします。ダウンタイムを発生させずにどのような方法で使用できますか？

Answer 1

ベストソリューションは、可能であればファイルシステムのスナップショットを使用することです。

oplogファイルが残りのデータファイルと同じディスクスペースにある限り、mongodノードを直接スナップショットすることができます。積極的なものを「シャットダウン」するなど、何もする必要はありません。

how to make restore with snapshot

次に、あなただけの新しいノードのデータディレクトリにそれらのファイルをコピーして、mongodプロセスを起動します。

ファイルシステムのスナップショットが不可能な場合は、作業中のmongodデータディレクトリのコピーを取るための別の方法がありますが、ダウンタイムが発生した場合は簡単です。ダウンタイムがない場合は、レプリカセットが基本的に「1つのノードRS」である間に、いつでも少数（2つ）のアービターを追加して他のセカンダリを一時停止することができます（データディレクトリのコピーを取る）。