ロールバックは、フェイルオーバー後に以前のプライマリがレプリカセットに再参加したときに、そのプライマリに対する書き込み (write) 操作を元に戻します。Atlas クラスターは、MongoDBのデフォルトの書込み保証 (write concern) として { w: "majority" } を使用します。このデフォルトでは、Atlas は書き込み (write) をノードの過半数にレプリケートした後にのみ認識します。認識された書き込み (write) はロールバックできないため、ロールバックによるデータ損失は発生しません。
{ w: 1 }書込み保証 (write concern)を構成すると、ロールバックはまだレプリケートされていない書き込み (write)に影響する可能性があります。ロールバックが発生する前に、ロールバックされた操作を識別する方法を計画し、再実行するかどうかを決定します。
レプリカセットのロールバックメカニズムについて詳しくは、レプリカセットのフェイルオーバー時のロールバックを参照してください。
Atlas におけるロールバックの動作
Atlas でロールバックが発生した場合、次の条件が適用されます。
Atlas はプロジェクトのアクティビティフィードで
HOST_ROLLBACKイベントを生成します。このイベントを確認する方法については、「ロールバックの検出」を参照してください。Atlas は、ロールバックされた操作のリストを維持しません。
書込み保証 (write concern)とロールバック リスク
Atlas クラスターは MongoDB のデフォルトの 書込み保証 (write concern) として { w: "majority" } を使用します。このデフォルトでは、ロールバックによるデータ損失は発生しません。構成する書込み保証 (write concern) によって、ロールバックによるデータ損失が発生するかどうかが決定されます。
{ w: "majority" }(デフォルト) — Atlas は、レプリカセットメンバーの過半数が書き込み (write) を確認した後にのみ、書き込み (write) を認識します。プライマリが降格する前に書き込み (write)が複製されたため、ロールバックにはこれらの書き込み (write)を含めることはできません。{ w: 1 }— Atlas は、プライマリが記録した後にのみ書き込み (write) を認識し、セカンダリへのレプリケーションを待たちません。書き込み (write)がレプリケーションされる前にプライマリがステップダウンすると、書き込み (write)がロールバックされ、データが復元できない可能性があります。
自己管理型の配置とは異なり、Atlas は、次のような日常のメンテナンス操作中にもレプリカセットの選挙をトリガーします。
ローリングメンテナンスとパッチの更新
クラスター階層の変更やディスク サイズの変更などの拡大イベント
一般的なクラスター構成の変更
Atlas は、ダウンタイムを回避するため、ローリングベースでこれらの操作を実行します。ただし、選挙ごとに、{ w: 1 } 書き込み (write) がセカンダリにレプリケートされない期間が発生します。{ w: 1 } を使用する場合は、ロールバックリスクの評価時にこれらの選挙ソースを考慮してください。
ロールバックの検出
Atlas は、フェイルオーバー中にロールバック状態を検出すると、HOST_ROLLBACK イベントを生成します。このイベントは次の方法で確認できます。
アクティビティフィード: プロジェクトのアクティビティフィードで
HOST_ROLLBACKイベントを表示します。学ぶには、「アクティビティフィードを表示」を参照してください。アラート:イベント発生時に通知を受信するように、
HOST_ROLLBACKイベントタイプでアラートを構成します。詳しくは、「アラート設定の構成」を参照してください。
注意
Atlas は、ソース クラスターとターゲット クラスター間のデータの違異により、ポイントインタイム復元操作中に HOST_ROLLBACK イベントを生成します。このコンテキストで発生した場合は、このイベントを無視できます。詳細については、「継続的なクラウドバックアップから復元する」を参照してください。
ロールバックされたデータを復元する
ロールバックが発生した場合は、MongoDB サポートにお問い合わせて、ロールバックされたデータの復旧が可能かどうかを確認してください。