ApsaraDB for MongoDB:データ復旧の概要

インスタンスデータを復元できる期間は、バックアップデータの保持期間によって異なります。より過去の時点からデータを復元したい場合は、「長期保存バックアップ」をご参照ください。

新しいインスタンスへのデータ復元に必要な時間は、ストレージタイプ、バックアップデータ量、再生する oplog 量、新しいインスタンスの仕様によって異なります。通常は数分から数時間です。

完全な復元は、次の 3 つのステージで構成されます。復元の合計時間は、3 つのステージにかかる時間の合計です：

復元時間に影響する要因

• ストレージタイプ：クラウドディスクベースのインスタンスのフル復元ではスナップショットをマウントします。ローカルディスクベースのインスタンスでのデータのダウンロードと展開よりも大幅に高速です。

• バックアップセットのサイズ：ローカルディスクベースのインスタンスでは、バックアップが大きいほどダウンロードに時間がかかります。この要因はクラウドディスクベースのインスタンスには影響しません。

• データファイル数：コレクションとインデックスが多いほど、ローカルディスクベースのインスタンスの展開時間が増加します。

• 新しいインスタンスの仕様：CPU コア数、メモリ、ディスク IOPS が多いほど、ダウンロード、展開、oplog の再生が高速化します。大容量データを低仕様のインスタンスに復元すると、所要時間が大幅に長くなります。

• oplog 量：ポイントインタイムリカバリでは、ターゲット時点がフルバックアップポイントから離れるほど、再生する oplog データが増えます。これにより復元時間が増加します。

• oplog 内容の複雑さ：oplog 内の複数ドキュメントトランザクションは直列に再生する必要があり、並列化で高速化できません。大きなドキュメントやホットスポット更新は追加の書き込み増幅を引き起こします。書き込みワークロードが複雑な場合、インスタンス仕様を上げても再生速度が目に見えて改善しないことがあります。

• ソースインスタンスの書き込みレート：ポイントインタイムリカバリでは、ソースの書き込みレートが高いほど、同じ期間に生成される oplog データが増えます。これにより再生時間が増加します。

• シャードクラスターインスタンス：シャードクラスターインスタンスの Config サーバー、シャード、および mongos ノードは並列に復元されます。完了時間は最も遅いコンポーネントに依存します。通常、同じデータ量のレプリカセットインスタンスより短くなることはありません。

復元時間を短縮するための推奨事項

• クラウドディスクベースのインスタンスを優先してください。フル復元は数分で完了し、データ量やコレクション数の影響を受けません。

• ソースインスタンス以上の仕様を選択してください。これにより、復元中の仕様ボトルネックを防止できます。

• バックアップポイントからのインスタンス作成を推奨します。業務上許容できる場合は、ターゲット時点に最も近いバックアップポイントを使用してください。これにより、oplog の再生時間を短縮または不要にできます。

• コレクションとインデックスの数を制限してください。未使用のコレクションとインデックスを速やかに削除すると、ローカルディスクベースのインスタンスの展開時間を大幅に短縮できます。

• 高頻度バックアップを有効にしてください。バックアップポイントとターゲット時点の間隔が短くなり、再生する oplog 量を削減できます。

シャードクラスターのクラウドディスクインスタンスの場合、データベースとテーブルの復元機能を使用して、データをソースインスタンスに復元できます。詳細については、「ApsaraDB for MongoDBインスタンスの1つ以上のデータベースの復元」をご参照ください。

インスタンスがデータベースとテーブルの復元機能を使用したソースインスタンスへのデータ復元をサポートしていない場合は、バックアップデータを新規インスタンスに復元できます。その後、ソースインスタンスと新規インスタンスのエンドポイントとポート番号を切り替えるか、Data Transmission Service (DTS) を使用して新規インスタンスからソースインスタンスにデータを移行できます。

• インスタンスのエンドポイントとポートを変更するには、「エンドポイントとポートの変更」をご参照ください。

• DTS を使用したデータ移行の詳細については、「セルフマネージドMongoDBデータベースまたはApsaraDB for MongoDBインスタンスの移行ソリューション」をご参照ください。

ダウンロードしたバックアップファイルを ApsaraDB for MongoDB インスタンスに直接復元することはできません。まずデータをセルフマネージドデータベースに復元し、次に DTS を使用してデータを ApsaraDB for MongoDB インスタンスに移行できます。DTS を使用したデータ移行の詳細については、「セルフマネージドMongoDBデータベースまたはApsaraDB for MongoDBインスタンスの移行ソリューション」をご参照ください。

• DTS を使用して、インスタンスデータをセルフマネージドデータベースに移行できます。詳細については、「セルフマネージドMongoDBデータベースまたはApsaraDB for MongoDBインスタンスの移行ソリューション」をご参照ください。

• MongoDB のネイティブなバックアップおよび復元ツールである Mongodump と Mongorestore を使用して、インスタンスをバックアップおよび復元できます。

シャードクラスターインスタンスの Config サーバーは、config.collections および config.chunks コレクションを含む、すべてのシャード化コレクションのルーティングメタデータを格納します。これらのコレクション内のドキュメントには、データが属するシャードを識別する shard: 'shard01' などのフィールドが含まれます。クローン復元ではソースインスタンスの完全なルーティングデータが必要なため、ソースのシャード ID (シャード名) を保持する必要があります。その結果、複製されたインスタンスのシャード ID は、sh.status() の出力に表示されるシャード名とは異なります。

コンソールのインスタンス詳細ページに表示される [シャード ID] (replicaSetName) と、sh.status() の出力を比較することで対応付けできます。この対応関係は復元後も変わりません。