バックアップの準備
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
クラスターまたはレプリカセットをバックアップする前に、データをバックアップする方法とバックアップするデータを決定します。 このページでは、バックアップを開始する前に考慮する必要がある項目について説明します。
バックアップ サイズの推奨事項
データのバックアップをサイズ化する場合は、レプリカセットのサイズを2 TB 以下の非圧縮データに管理します。 データベースの非圧縮データが2 TB を超えた場合:
データベースのシャード
各シャードの非圧縮データは 2 TB 以下である
これらのサイズに関する推奨事項はベストプラクティスです。 これらは MongoDB database または Cloud Manager の制限ではありません。
バックアップと復元では、大量の CPU、メモリ、ストレージ、ネットワーク帯域幅を使用する可能性があります。
例
10 GBps や 100 GBps などの記載されたネットワーク スループットは、論理的な最大値です。 その値は、ネットワーク トラフィックの共有または調整を考慮していません。
次のシナリオを検討してみましょう。
2 TB のデータベースをバックアップする場合。
ホストは Cloud Manager からバックアップ ストレージへの 10 Gbps TCP 接続をサポートしています。
ネットワーク接続では、パケットロスが非常に少なく、ラウンドトリップ遅延時間が短いです。
データの完全なバックアップが完了するまでに 30 時間以上かかります。 [1]
これにはディスクの読み取りおよび書込み速度は考慮されません。これは、単一またはミラーリングされた NVMe ストレージ デバイスで最大 3 Gbps の読み取りと 1 Gbps の書込みを超える可能性があります。
連続する各増分バックアップを完了するのに必要な時間は、書込み負荷によって異なります。
このデータベースを 4 つのシャードにシャードすると、各シャードはバックアップを個別に実行します。 これにより、バックアップが完了するまでの時間は 8 時間未満になります。
| [1] | これらのスループット数値は、 ネットワーク スループット 計算子 を使用して計算されています。 および は、追加のネットワーク圧縮がないことを前提としています。 |
スナップショット頻度と保持ポリシー
デフォルトでは、Cloud Manager は 6 時間ごとにデータの基本スナップショットを取得します。
必要に応じて、管理者はベース スナップショットの頻度を 6 時間、8 時間、12 時間、または 24 時間に変更できます。 Cloud Manager はスケジュールでスナップショットを自動的に作成します。オンデマンドでスナップショットを取得することはできません。
Cloud Manager は、次の表に記載されている期間のスナップショットを保持します。
配置の バックアップ を終了すると、Cloud Manager は現在の保持ポリシーの期間内のスナップショットを直ちに削除します。
配置の バックアップ を停止すると、Cloud Manager は新しいスナップショットの取得を停止しますが、リストされている有効期限が切れるまで既存のスナップショットを保持します。
スナップショット | デフォルトの保持ポリシー | 最大保持ポリシー |
|---|---|---|
基本スナップショット | 2 日 | 5 日間（頻度が 24 時間の場合は 30 日間） |
毎日のスナップショット | 7 日間 | 1 年 |
週次スナップショット | 4 週間 | 1 年 |
月次スナップショット | 13か月 | 7 年 |
スナップショット スケジュールの変更は、スナップショット ストレージのコストに影響を与えます。
バックアップ配置のスケジュールは、 Backupページから利用可能な Edit Snapshot Scheduleメニューのオプションを使用して変更できます。 管理者は、 API の snapshotSchedule リソースを使用して、スナップショット頻度と保持を変更できます。
Cloud Manager ではスナップショットの参照時間を変更できません。
制限
Cloud Manager は、配置上のコレクションの合計数が
100,000以上の配置をバックアップしません。Cloud Manager は、インデックス コレクション オプションを複製しません。
暗号化
WiredTiger 暗号化を使用してバックアップを保存することはできません。 暗号化を有効にしない場合は、WiredTiger ストレージ エンジンを使用してバックアップを保存できます。 バックアップから復元する場合、暗号化されていないファイルが復元されます。
バックアップに関する考慮事項
整合性とスナップショット
MongoDB バージョン 4.2 以降を実行しているクラスターの場合:
Cloud Manager は、 collStats と によって報告されるサイズ統計を除き、スナップショットを取得する際に 因果整合性 を維持します。
db.[collection].count()collStatsおよびdb.[collection].count()によって報告されるサイズ統計が不正確になる可能性があります。Cloud Manager は、シャーディングされたクラスターのすべてのシャードにわたって時間を調整します。 これにより、スケジュールされたスナップショット時点ですべてのシャードとノードに書き込まれたすべてのドキュメントがスナップショットに含まれるようになります。
MongoDB バージョン 4.0 以前を実行しているクラスターの場合:
Cloud Manager はクラッシュに対応したスナップショットを維持します。
Cloud Manager は、シャーディングされたクラスターとコンフィギュレーションサーバーのレプリカセットの各シャードからほぼ同時にスナップショットを取得します。
FCV 4.2 以降を実行しているデータベース
現在サポートされているバックアップ機能
機能 | FCV 4.2 以降を実行しているデータベース | FCV 4.0 以前を実行しているデータベース |
|---|---|---|
WiredTiger スナップショットを使用したデータのバックアップ | ||
バックアップデーモンを使用したデータのバックアップ | ||
レプリカセットのバックアップ | ||
シャーディングされたクラスターのバックアップ | ||
名前空間を使用してフィルタリングが可能になりました [2 ] | ||
同期ソース データベースを指定可能 | ||
特定の時点にデータを復元可能 [3 ] | ||
増分バックアップを実行可能 [4 ] | ||
KMIP 暗号化を使用するスナップショットをサポートするようになりました [5 ] | ||
ローカルキー暗号化 を使用するスナップショットをサポートする [6 ] | ||
S3スナップショット ストレージへの保存をサポート | ||
MongoDB Enterprise を実行しているデータベースをサポート | ||
MongoDB Community を実行しているデータベースをサポート | ||
| [2] | 名前空間フィルタリングは、Cloud Manager バージョン 6.0.8 以降でのみサポートされています。 MongoDB 配置には、 4.0以前または6.0.1以降のfeatureCompatibilityVersion値が必要です。 |
| [3] | PIT復元を実行するにはMongoDB Ops Manager 4.2.13 以降が必要です。 |
| [4] | Cloud Manager では、スナップショットが削除された後、およびブロックストア ブロック サイズが変更された場合は、最初のバックアップに完全なバックアップが必要です。 増分バックアップにより、ネットワーク転送とストレージのコストが削減されます。この機能は以下と連携します。
|
| [ 5 ] | 暗号化されたスナップショットをクエリするには、 MongoDB Enterprise 4.2.9以降、または4.4.0以降が必要です。 |
| [ 6 ] | FCV 4.2以降のバックアップは、ローカルキーの暗号化をサポートしていません。 |
| [ 7 ] | FCV 4.2以降のデータベースへのファイルシステム ストアへのバックアップはFile System Store Gzip Compression Levelを無視します。 |
要件と制限事項
MongoDB 4.2以降をFCV 4.2以降で実行している場合にバックアップと復元を実行するには、次の操作を実行します。
ブロックストア ブロック サイズの変更を考慮する必要があります。 ブロック サイズを設定せず、デフォルトを使用した場合、そのブロック サイズは 64 KB から 1 MB に変更されます。 これはストレージの使用に影響を与える可能性があります。
レプリカセット構成内のホスト名が MongoDB Agent が使用するホスト名と一致していること、またはホスト マッピングに正しいホスト名が含まれていることを確認する必要があります。 rs.conf()を使用してレプリカセットの構成を確認できます。
MongoDB 6.0以降を実行している場合にのみ、 名前空間フィルター リスト を使用してバックアップに含まれる名前空間を定義できます。 MongoDB 4.2から5.0のバージョンで取得されたスナップショットには、常にすべての名前空間が含まれます。
同期ソース データベースは必要ありません。 スナップショットを作成する際、Cloud Manager はパフォーマンスへの影響が最も少なく、スナップショットデータのストレージレベルの重複が最も大きいレプリカセットのメンバーを選択します。
クラスター内のすべての
mongodノードを使用して MongoDB Agent を配置する必要があります。
注意
Cloud Manager がクラスターを管理しない場合、
backupclusterAdminバックアップを実行する MongoDB ユーザーに } ロールと ロールを 付与 します。MongoDB Agent を実行するオペレーティング システム ユーザーが、配置のすべてのデータファイル（ジャーナル ファイルを含む）に対する読み取り権限があることを確認します。
FCV 4.0 以前を実行しているデータベース
重要
シャーディングされたクラスターまたはレプリカセットのみをバックアップできます。 スタンドアロンのmongodプロセスをバックアップするには、それを単一ノードのレプリカセットに変換する必要があります。
次の考慮事項は、データベースが MongoDB 4.0 またはそれ以前のバージョンを実行している場合、または MongoDB 4.2 を実行している場合に適用されます。
"featureCompatibilityVersion" : 4.0
期限切れのスナップショットのガベージ コレクション
Cloud Manager は グルーム ジョブ を使用して期限切れのスナップショットを管理します。 これらのグルーム ジョブは、スナップショットが含まれるスナップショット ストアに応じて異なる動作をします。
スナップショットストア | グルーミング ジョブの仕組み |
|---|---|
MongoDB ブロックストア | 各ジョブのライブ ブロックの量まで追加のディスク領域を使用します。 |
ファイルシステム スナップショットの保存 | 期限切れのスナップショットを削除します |
S3 スナップショット保存 | グルーム ジョブの実行中に Cloud Manager がスナップショットを作成する場合、追加のディスク領域を使用する可能性があります。 Cloud Manager は S3 スナップショット ストアで同時グルーム ジョブを実行できます。 |
注意
スナップショット ジョブとグルーム ジョブは同時に実行することはできません。 スナップショット ジョブの実行中にグルーム ジョブを開始すると、グルーム ジョブは失敗し、 MongoDB Ops Managerはエラーをログに記録し、スナップショット ジョブが完了するとグルーム ジョブを自動的に再試行します。 グルーム ジョブの実行中にスナップショット ジョブを開始すると、スナップショット ジョブは失敗し、 MongoDB Ops Managerはエラーをログに記録し、グルーム ジョブが完了した後にスナップショット ジョブを再試行します。
名前空間フィルター
名前空間フィルターを使用すると、バックアップするデータベースとコレクションを指定できます。 除外するコレクションのBlacklistまたは含めるコレクションのWhitelistを作成します。 バックアップを開始するときに選択を行い、後で必要に応じて編集できます。 フィルターを変更してバックアップにデータを追加する場合は、 再同期 が必要になります。
ホワイトリストを使用して、ログ データ、キャッシュ、またはその他のエフェメラル データを含むコレクションのバックアップを防止します。 このようなデータベースとコレクションを除外すると、バックアップ時間とコストを削減できます。 バックアップするすべての名前空間を意図的にオプトインする必要があるため、ホワイトリストをホワイトリストとして使用するよりもブラックリストを使用する方が適しています。
注意
名前空間フィルタリングは、Cloud Manager バージョン6.0.8以降でのみサポートされています。 MongoDB 配置には、 4.0以前または6.0.1以降のfeatureCompatibilityVersion値が必要です。
ストレージ エンジン
MongoDB クラスターをバックアップするには、 WiredTiger storage engineストレージ エンジン を使用します。
現在のバッキング データベースで MMAPv1 を使用している場合は、WiredTiger にアップグレードします。
WiredTiger を使用すると、Cloud Manager はバックアップを 100,000 未満の配置に制限します。 ファイルには、コレクションとインデックスが含まれます。
MongoDB 4.2は MMAPv 1ストレージを削除します。 ストレージ エンジンの詳細については、MongoDB マニュアルの「ストレージ」を参照してください。
本番環境の配置の再同期
本番環境では、バックアップされたすべてのレプリカセットを 1 年ごとなど定期的に再同期します。 再同期すると、各レプリカセット内の セカンダリ からデータが読み取られます。 再同期中は、新しいスナップショットは生成されません。
次の場合は、バックアップを再同期することをお勧めします。
データのサイズを小さくすると、ディスク上の Cloud Manager のデータのコピーのサイズも小さくなります。
TTL インデックスを作成し、ドキュメントを定期的に削除します。
コレクションを削除します（MMAPv 1のみ）。
シャーディングされたクラスターを実行し、特定のシャードからチャンクを移動します。
Cloud Manager が新しいストレージエンジン形式でスナップショットを提供する場合は、ストレージエンジンを切り替えます。
チェックポイント
重要
MongoDBをFeature Compatibility Version の4.0 またはそれ以前のバージョンで実行するクラスターにはチェックポイントを使用できます。FCV 以降のMongoDBインスタンスからチェックポイントが削除されました。4.2
シャーディングされたクラスターの場合、 チェックポイント はスナップショット間の追加の復元ポイントを提供します。 チェックポイントを有効にすると、Cloud Manager はスナップショット間の15 、 30 、または60分の構成可能な間隔で復元ポイントを作成します。 チェックポイントを有効にするには、「 チェックポイントの有効化 」を参照してください。
チェックポイントを作成するために、Cloud Manager は バランサー を停止し、クラスター内の各 シャード とコンフィギュレーション サーバー の oplog にトークンを挿入します。これらのチェックポイント トークンは軽量で、パフォーマンスやディスク使用量に影響を与えません。
バックアップにはチェックポイントは必要なく、デフォルトで無効になっています。
チェックポイントから復元するには、Cloud Manager がチェックポイントの前にキャプチャされた最後のスナップショットに各シャードとコンフィギュレーションサーバーのoplogを適用する必要があります。 チェックポイントからの復元は、スナップショットからの復元よりも時間がかかります。
エージェントがバランサーを停止できない場合のスナップショット
FCV 4.0またはそれ以前のバージョンで実行されているシャーディングされたクラスターの場合、Cloud Manager はクラスターのスナップショットを取得する前にバランサーを無効にします。 長時間の移行やmongosが実行されていない場合など、特定の状況では、Cloud Manager はバランサーを無効にしようとしますが、失敗します。 このような場合、Cloud Manager はクラスターのスナップショットを引き続き取得しますが、データが不完全または不整合な状態である可能性があるスナップショットにフラグを付けます。 アクティブなバランシング操作中に取得されたクラスター スナップショットでは、データが失われる、またはデータが孤立している間に取得されたクラスター スナップショットのリスクがあります。
エージェントが に接続できない場合のスナップショット mongod
シャーディングされたクラスターの場合、バックアップがmongodプロセス（シャードでもコンフィギュレーションサーバーでも）に到達できない場合、エージェントは同期oplogトークンを挿入できません。 このような場合、Cloud Manager はスナップショットを作成せず、警告メッセージを表示します。