MySQL から MongoDB に切り替えたいのですが、大量のデータ損失 (1 時間以上) は受け入れられません。
3 つのバックアップ プランが必要です。
時間単位のバックアップ プラン。データは X 分ごとにディスクにフラッシュされます。サーバーに問題が発生した場合、再起動後、少なくとも 1 時間前まではすべてのデータが保持されていることを確認します。構成できますか?
毎日のバックアップ計画。データは毎日バックアップ ディスクに同期されるため、サーバーが爆発しても数時間で昨日のデータを復元できます。fsync、master-slave、または何か他のものを使用する必要がありますか? トラフィックを最小限に抑えたいので、理想的には変更のみが送信されます。
毎週のバックアップ計画。データは 2 番目のバックアップ ディスクに同期されるため、サーバーと最初のバックアップ ディスクの両方が爆発した場合でも、少なくとも先週のデータは保持されます。これは信頼性の問題なので、すべてのデータをネットワーク経由で送信しても問題ありません。
どうすればいいですか？
このfsyncコマンドは、データをディスクにフラッシュします。デフォルトでは60秒ごとに実行されますが、--syncdelayコマンドラインパラメーターを使用して構成できます。
バックアップに関するドキュメントには、毎日および毎週のバックアップに関するいくつかの良い指針があります。毎日のバックアップの場合、変更を同期するだけなので、マスタースレーブ構成が最適なオプションのようです。
毎週のバックアップには、マスタースレーブ構成またはレプリケーションを使用することもできます。もう1つのオプションは、データベース全体をバックアップするmongodumpユーティリティです。データベースの実行中にバックアップを作成できるため、メインデータベースまたはスレーブの1つで実行できます。バックアップする前にスレーブをロックすることもできます。
automongobackupを使用できるかもしれません。
バックアップ ソリューションを完全に外部委託する場合、MongoDB Management Serviceは 6 時間ごとにスナップショットを取得します。スナップショットのデフォルトの保持ポリシーでは、24 時間のポイントインタイム リストア、1 週間の毎日のスナップショット、1 か月の毎週のスナップショット、1 年間の毎月のスナップショットを取得できます。
このFAQには、完全な保持ポリシーがあります。
バックアップ サービスは、oplog を読み取ることによってレプリカ セットを継続的にバックアップするため、オーバーヘッドは完全なローカル定期スナップショットよりも低くなります。