ローリングメンテナンス:
- oplog の時間を確認するには、セカンダリをダウンさせてキャッチアップします: db.printReplicationInfo()
- Primary、Secondary、Arbiter を使用している場合、Secondary を削除するとリスクが生じる可能性があります。メンテナンス期間中に何かが発生した場合に備えて、プライマリにはフェイルオーバーがありません。Primary-Secondary-Secondary の方が安全です。
- セカンダリをシャットダウンした後、 --replSet オプションを指定せずに再起動し、別のポートで再起動します。そうしないと、replicaSet の残りの部分が混乱します。
- --replSet を使用してセカンダリを再起動すると、古いポートが再びそれを ReplicaSet に追加します。ご心配なく。あなたのプライマリーはプライマリーのままです。投票/選挙は、プライマリが消えたときに「のみ」発生します...セカンダリを追加する場合はそうではありません。
- セカンダリは oplog に追いつきます。
- 初等協会で働くこと。プライマリで rs.stepDown() を実行し、セカンダリに引き継がせて、プロセスを繰り返します。
ローリングメンテナンス中のクリーンアップ
これについてはまだテストしていないので、今のところ推測することしかできません。ローリングメンテナンス中にできることは次のとおりです。
- バイナリの更新 (apt-get update/yum update/...)
- インデックスを構築する
- コンパクトにして修理
データの削除について ローカルの小さなレプリカでテストする必要があること。
- 残念ながら、ダンプ/復元は悪い考えです。確信はないけど。
- removeステートメントを実行します...それを行う方法があると思います。そのステートメントをプライマリで実行させますが、まだ方法がわかりません。
- 最も単純な例: プライマリで remove ステートメントを実行し、それをセカンダリに広げてみませんか? データベースのサイズを小さくしたいからですか?さて、取り外した後、ローリングメンテナンスを実行して修復を行うことができます. Compact は余分なスペースを作成せず、事前に割り当てられたファイル内のデータのみを並べ替えます。そして修理、注意してください、構築するには2倍のスペースが必要です。修復を行うには、100 GB の DB に少なくとも 100 GB の空き容量が必要です。
https://dba.stackexchange.com/questions/28269/disk-space-recovery-on-mongodb-replicaset-secondaries
https://university.mongodb.com => M202: MongoDB Advanced Deployment and Operations ...をご覧ください。この問題は、これらの無料レッスンで扱われます。