バックアップ プロセス
バックアップは、データベースがどの MongoDB のバージョンと 互換性 があるかによって異なります。 この機能の互換性バージョンは、現在のバージョンから 1 つ前のバージョンまでの範囲です。 MongoDB 4.2の場合、FCV は 4.0または4.2になります。
バックアップ プロセスでは、 のスケジュールされたスナップショット間隔でデータディレクトリのスナップショットが作成されます。 このプロセスでは、 MongoDBデプロイメント内のデータファイルがコピーされ、 MongoDB Ops Managerを介してネットワーク経由で既存のスナップショットストレージに送信されます。 配置では、コピー プロセス中に読み取りおよび書込み操作を引き続き処理できます。
スナップショットがどのようにストアされているかに関係なく、バックアップ プロセスはこのように機能します。
注意
新しいバックアップ プロセスでは、最初の同期はなくなりました。 最初の同期がない結果、 MongoDB Ops Managerは、 renameCollection を頻繁に使用するような、より幅広いカスタマーをサポートできます。
バックアップが開始されると、 MongoDB Ops Managerは継続的かつ連続的なプロセスとしてデータをバックアップします。 このプロセスでは、ヘッドデータベースがデータベースと同期されている限り、スナップショットの作成が続行されます。
このプロセスはレプリカセットのデータ同期と同様に機能します。
バックアップ プロセス:
最初の同期を実行して、既存のすべてのデータを現在の状態でバックアップします。 シャーディングされたクラスターでは、これは各シャードとコンフィギュレーションサーバーで発生します。
注意
最初の同期を再開する条件またはアクション
最初の同期プロセス中に特定のアクションまたは条件によって最初の同期プロセスが再開される場合があります。 次のアクションと条件を避けてください。
最初の同期中に回避するアクションは次のとおりです。
再起動、シャットダウン、またはソースデータベースのバージョンまたは FCV値の変更。
ソースデータベースのコレクションの名前を変更します。
ソースデータベースの 集計パイプライン での$out値の変更。
MongoDB Ops Managerアプリケーションまたはバックアップデーモンの再起動またはシャットダウン。
最初の同期中に回避する条件は次のとおりです。
ヘッドディレクトリがいっぱいになっています。
MongoDB Ops Managerコンポーネント間のネットワーク接続は不安定です。
スナップショット スケジュールで指定された頻度で配置内の
dataディレクトリのスナップショットを取得し、そのスナップショットをストレージ システムに転送します。注意
シャーディングされたクラスターでは、 チェックポイント を有効にして、スナップショット間のポイントインタイム復元を許可することもできます。 シャーディングされたクラスターがチェックポイントを使用する方法については、「チェックポイント 」を参照してください。
重要
4.0またはそれ以前の機能の互換性バージョンで MongoDB を実行するクラスターのチェックポイントを使用できます。 FCVが4.2以降の MongoDB インスタンスからチェックポイントが削除されました。
oplogを継続的に監視し、最新のバックアップに新しいデータベース操作を追加して、データのローカルMongoDB Ops Managerコピーを最新の状態に維持します。
スナップショットがどのようにストアされているかに関係なく、バックアップ プロセスはこのように機能します。
バックアップ定義と運用状態
各バックアップはジョブとして定義されます。 Each job defines how much and how often data is backed up. バックアップ ジョブはプロジェクトごとに定義されます。
動作状態
次の表に、バックアップジョブの状態を示します。
状態 | 古いスナップショットの保持 | 新しいスナップショットの作成 |
|---|---|---|
Active | はい | はい |
Stopped | はい | No |
Inactive | No | No |
状態 | 古いスナップショットの保持 | 新しいスナップショットの作成 | Oplog の適用 |
|---|---|---|---|
Active | はい | はい | はい |
Stopped | はい | No | No |
Inactive | No | No | No |
運用状態の変更
プロジェクトのバックアップ ジョブがアクティブになると、停止または終了されるまで、それ以上の介入なしに実行されます。 演算子は、次の方法でバックアップの状態を変更できます。
初期状態 | 目的の状態 | 方式 |
|---|---|---|
Inactive | Active | [Start] をクリックします。 |
Active | Stopped | [Stop] をクリックします。 |
Stopped | Active | [Restart] をクリックします。 |
Stopped | Inactive | [Terminate] をクリックします。 警告: Terminate は保持されているすべてのバックアップを削除します。 |
初期状態 | 目的の状態 | 方式 |
|---|---|---|
Inactive | Active after Initial Sync | [Start] をクリックします。 |
Active | Stopped | [Stop] をクリックします。 |
Stopped | Active after Initial Sync | [Restart] をクリックします。 |
Stopped | Inactive | [Terminate] をクリックします。 警告: Terminate は保持されているすべてのバックアップを削除します。 |
重要
バックアップジョブに対してBackup requires a resyncアラートが表示される場合があります。 これにはバックアップの再同期が必要になる場合があります。 これは別の状態ではなく、新しいバックアップ プロセス フローのトリガーです。 Initial
Syncが完了すると、バックアップジョブは再度Activeになります。
バックアップ処理フロー
バックアップ ジョブが作成されると、次のプロセスフローを通過します。
クラスターがスケジュールされたスナップショットの準備ができたら、スナップショットを取得するために最適に使用可能なノードを決定します。 ほとんどの場合、
mongodは、優先順位が最も低いセカンダリ メンバーを優先スナップショット ノードとして決定します。 セカンダリ が プライマリ や以前に選択されたスナップショットのノードとどの程度現在可能かなど、他のメトリクスが優先ノードを決定する際に考慮される可能性があります。mongodプロセスがスナップショットの元のノードを決定すると、バックアップ プロセスはターゲット ノードで$backupCursorを開きます。ストレージ エンジン層である
$backupCursorを使用すると、書込みを受け入れながらストレージ内のデータベースファイルを一貫した状態でコピーできます。MongoDB Agent バックアップ 機能は、これらのデータファイルをコピーして処理します。
MongoDB Agentバックアップ 機能は、データファイルをMongoDB Ops Managerに送信します。
バックアップ プロセスではこれらのファイルが収集され、バックアップの保存対象として選択したスナップショット ストアに転送されます。 スナップショットを保存するために選択したスナップショットストアに応じて、スナップショットは次のように書き込むことができます。
ブロックストアへのブロック ホスト上の database に書き込まれたバイナリMongoDBMongoDB Ops Manager チャンク。
Amazon Web Services S3 バケットへのブロック。 これらのブロックのメタデータは、MongoDB MongoDB Ops Managerホスト上の database に書き込まれます。
注意
各ストレージ方法の特徴の詳細については、「バックアップ構成オプション 」を参照してください。
初期バックアップ
バックアップ対応の MongoDB Agent は、バックアップジョブに関連付けられているデータベースに接続し、認証します。
最初の同期が開始され、
startingフェーズに入ります。 最初の同期はInactiveとActiveの間の過渡状態です。 最初の同期は、進行状況を示すためにBackupページに表示される一連のフェーズを通じて行われます。 バックアップは、スライスと呼ばれるドキュメントの 10 MB 圧縮バンドルで既存のデータをMongoDB Ops Managerにストリーミングします。 バックアップは、スナップショットが作成された点でのスライスを作成します。 MongoDB Ops Managerは、スナップショットが個別に起動すると、 インスタンスに挿入されたデータをキャプチャします。transferringフェーズは、スライスがストリーミングされ、バックアップデーモンに代わってoplogストアに一時的に保存されると開始されます。 バックアップデーモン サービスは、他のバックアップ ジョブの処理を犠牲にして、大規模な最初の同期スライスを処理することに専有することはできません。 oplogストアは、バックアップデーモンがスライスを取得できるようになるまでスライスを保存します。 oplogストアは、最初のスナップショット ストアが作成されたときに作成されます。バックアップがデータをストリーミングしている間は、 oplogが追跡されます。 このテーリングでは、バックアップが開始されたときの配置データベースの状態と配置データベースの現在の状態との間の違いを収集します。 oplog エントリは、 oplog スライスと呼ばれる10 MB の圧縮ドキュメント バンドルで送信されます。 これらの 2 つのスライスのストリームは並行して収集され、完全なスナップショットの作成に必要な時間が短縮されます。
buildingフェーズは、MongoDB Ops Manager が最初の同期スライスの最初のバッチを受信すると開始されます。 このフェーズでは、 MongoDB Ops Managerは、バックアップデーモン サービスを実行しているホスト上にヘッドデータベースと呼ばれるバックアップ データベースのローカル バージョンを作成します。MongoDB Ops Managerは バックアップデーモン サービスを使用して、 oplogストアに保存されているドキュメントを ヘッドデータベース に挿入します。
MongoDB Ops Managerが追尾するoplogエントリをヘッドデータベースに適用すると、
applying oplogsフェーズが開始されます。fetching missing documentsフェーズでは、 MongoDB Ops Managerは配置データベースでドキュメントの挿入中に欠落したドキュメントをクエリします。 MongoDB Ops Managerは、配置データベースで見つかった欠落ドキュメントをヘッドデータベースに挿入します。欠落しているドキュメントを挿入した後、 MongoDB Ops Managerがヘッドデータベースの配置データベースにあるすべてのインデックスを作成するため、
creating indexesフェーズが開始されます。 インデックスが完了すると、最初の同期は終了し、 フェーズはcompleteに変わります。スナップショットを保存するために選択したスナップショットストアに応じて、スナップショットは次のように書き込むことができます。
ブロックストアへのブロック
Amazon Web Services S3 バケットへのブロック。 これらのブロックのメタデータは、MongoDB MongoDB Ops Managerホスト上の database に書き込まれます。
注意
各ストレージ方法の特徴は、「バックアップ構成オプション 」で説明されています。
その後のバックアップ
ヘッドデータベースは、配置データベースの完全なコピーとして機能します。 配置データベースとデータを同期させるには、定期的に oplog を適用する必要があります。 スナップショットは、スナップショット スケジュールに従って、ヘッドデータベースに保存されているデータから生成されます。
最初の完全バックアップが完了すると、アクティブな各バックアップジョブがこのプロセスに従います。
バックアップは、配置の oplog を追跡します。
バックアップでは、新しいoplogエントリがoplogスライスに定期的にバッチされ、 MongoDB Ops Managerに転送されます。
MongoDB Ops Managerは、 oplogエントリをoplogストア に保存します。
MongoDB Ops Managerは、 oplogスライスからの新しいoplogエントリを、配置バックアップを保存するヘッドデータベースに適用します。
MongoDB Ops Managerは新しいスナップショットを作成し、スナップショット スケジュールで指定されたスナップショット ストアに保存します。