大規模なコレクションの定期的なデータ アーカイブを依頼しています。要件のいくつかの点が私からいくつかの懸念を引き起こしています:
- アーカイブされたデータは、本番環境と同等のアプリケーション アクセスのために別のデータベースに移動する必要があります。
- バックアップの頻度は、毎月、毎年、またはそれ以下にすることもできます。
- 実稼働システムの可用性とパフォーマンスを中断することなく、アーカイブを実行する必要があります。
この要件は、アーカイブが実行されている短い時間枠での大容量の挿入と削除を意味します。対処すべき課題がいくつかあります。
- 同じレコードの場合、削除は挿入が成功した後にのみ発生し、発生する必要があります。
- 大量の挿入と削除は、レプリケーションがレプリカセットのセカンダリ ノードに完了する前に oplog を吹き飛ばす可能性があります。結局のところ、oplog のサイズは通常、日常的な操作用に設定されます。
課題 1 については、Mitch Pronschinske がここで非常に近い解決策を提案しています。Mitch のアーカイブ機能は、削除が挿入の成功後にのみ発生する可能性があるが、「発生する必要がある」部分では発生しないという問題に対処しています。それにもかかわらず、これは非常に近いものであり、このスクリプトの上に「発生する必要がある」部分に対処することが可能です。
私に頭痛を引き起こすのはチャレンジ2です。MongoDB の指示によると、oplog のサイズを変更するには、ダウンタイムと手動の介入が必要です。要件 3 を考慮すると、これはオプションではありません。
これをどのように達成できるかについて、誰か経験やアドバイスがありますか? ありがとう！
私の環境情報：
- モンゴDB 3.2
- シャード3個
- レプリカセット: 3 つのデータ メンバー、1 つのメンバーは優先度 0 で地理的に冗長です。
- OS:MS Win2012R2