Docs Menu
Docs Home
/
MongoDBマニュアル
/
自己管理型配置
/
管理
/
バックアップ 方法
/
シャーディングされたクラスターの復元

ファイルシステム スナップショットによる自己管理型シャーディングされたクラスターのバックアップ

項目一覧

  • Overview
  • Considerations
  • 始める前に
  • 手順

Overview

このドキュメントでは、 のシャーディングされたクラスターのすべてのコンポーネントのバックアップを作成する手順について説明します。 この手順では、ファイルシステムのスナップショットを使用して、 mongodインスタンスのコピーを取得します。

重要

シャーディングされたクラスターをバックアップするには、クラスターへの書き込みを すべて 停止する 必要 があります。

MongoDB のバックアップとシャーディングされたクラスターのバックアップの詳細については、「自己管理型配置のバックアップ メソッド 」および「 自己管理型シャーディングされたクラスターのバックアップと復元 」を参照してください。

Considerations

シャード間のトランザクション

ファイルシステムのスナップショットを使用してバックアップを作成するには、まずバランサーを停止し、書き込みを停止して、クラスター上のすべてのスキーマ変換操作を停止する必要があります。

MongoDB は、バランサーと実行中のトランザクションを次のサービスを通じて実行できるバックアップと復元操作を提供します。

  • MongoDB Atlas

  • MongoDB Cloud Manager

  • MongoDB Ops Manager

暗号化ストレージエンジン（MongoDB Enterprise のみ）

AES256-GCM暗号化モードを使用する暗号化ストレージ エンジンの場合、 AES256-GCMはすべてのプロセスについて、キーと一意のカウンター ブロック値を使用することを求めます。

AES256-GCM 暗号で構成されたストレージ エンジンの場合:

  • ホット バックアップからの復元
    バージョン 4.2 以降、「ホット」バックアップ（mongod が実行されている状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出し、データベース キーを自動的にロールオーバーして、IV（Initialization Vector: 初期化ベクトル）の再利用を回避できるようになりました。
  • コールド バックアップからの復元

    ただし、「コールド」バックアップ（mongod が実行されていない状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出できず、IV を再利用すると、機密性と整合性における保証が無効になります。

    バージョン 4.2 以降では、コールド ファイルシステム スナップショットから復元した後にキーが再利用されるのを回避するため、MongoDB に新しいコマンド ライン オプション --eseDatabaseKeyRollover が追加されました。--eseDatabaseKeyRollover オプションを使用して起動すると、mongod インスタンスは AES256-GCM 暗号で構成されたデータベース キーをロールオーバーして終了します。

バランサー

バックアップを取得する前に、 バランサー を停止することが 重要 です。

バックアップの取得中にバランサーがアクティブな場合、チャンクはバックアップを記録中に移行する可能性があるため、バックアップアーティファクトが不完全であるか、重複データが含まれている可能性があります。

精度

この手順では、クラスター バランサーを停止してコンフィギュレーションデータベースのバックアップを取得し、ファイルシステム スナップショット ツールを使用してクラスター内の各シャードのバックアップを取得します。 システムの正確な時点のスナップショットが必要な場合は、ファイルシステムのスナップショットを取得する前にすべての書き込みを停止する必要があります。それ以外の場合、スナップショットは特定の時間のみを近似します。

整合性

シャーディングされたクラスターをバックアップするには、 fsyncコマンドまたはdb.fsyncLock()メソッドを使用してクラスターへの書込みを停止する必要があります。 そのため、バックアップ内の不整合が発生する可能性を減らすことができます。

注意

これらの手順は、完全に実行され、開始時に操作が進行中でない場合にのみ、一貫性のあるバックアップを生成できます。

RAID 10 構成の Amazon EBS を使用したスナップショット

インスタンス内で RAID が構成された Amazon の EBS（Elastic Block Storage）上での配置に依存している場合、プラットフォームのスナップショットツールを使用してすべてのディスクで一貫性のある状態を取得することは不可能です。別の方法として、次のいずれかを実行することができます。

バージョンの互換性

この手順には、 mongosからの fsync ロックをサポートするバージョンの MongoDB が必要です。

MongoDB 7.1以降（ 7.0.2以降でも利用可能 ）、 6.0.11と5.0 。 22 ）、 fsyncコマンドとfsyncUnlockコマンドをmongosで実行し、シャーディングされたクラスターをロックおよびロック解除します。

始める前に

MongoDB 8.0以降では、 directShardOperationsロールを使用して、シャードに対してコマンドを直接実行する必要があるメンテナンス操作を実行できます。

警告

directShardOperationsロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。 directShardOperationsロールは、メンテナンス目的で、または MongoDB サポートのガイダンスに必ず従う必要があります。 メンテナンス操作を実行したら、 directShardOperationsロールの使用を停止します。

手順

シャーディングされたクラスターの自己管理型バックアップを作成するには、次の手順を実行します。

1

バックアップ ウィンドウの検索

チャンクの移行、再シャーディング、およびスキーマ移行の操作により、バックアップに不整合が生じる可能性があります。 バックアップを実行するのに適した時間を見つけるには、アプリケーションとデータベースの使用状況をモニターし、これらの操作が発生する可能性が低い時間を見つけます。

詳細については、「自己管理型シャーディングされたクラスターのスケジュール バックアップ ウィンドウ 」を参照してください。

2

バランサーを停止する

チャンクの移行によってバックアップが中断されるのを防ぐには、 sh.stopBalancer()メソッドを使用してバランサーを停止します。

sh.stopBalancer()

現在バランシング ラウンドが進行中の場合、 操作はバランシングが完了するまで待機します。

バランサーが停止していることを確認するには、 sh.getBalancerState()メソッドを使用します。

use config
while( sh.isBalancerRunning().mode != "off" ) {
   print("waiting...");
   sleep(1000);
}
3

クラスターのロック

データベースへの書込み (write) はバックアップの不整合を引き起こす可能性があります。 シャーディングされたクラスターをロックして、データベースを書込み (write) から保護します。

シャーディングされたクラスターをロックするには、 db.fsyncLock()メソッドを使用します。

db.getSiblingDB("admin").fsyncLock()

次の集計パイプラインを、コンフィギュレーションサーバーのmongosとプライマリmongodの両方で実行します。 ロックを確認するには、 fysncLockedフィールドがtrueを返し、 fsyncUnlockedフィールドがfalseを返すことを確認します。

db.getSiblingDB("admin").aggregate( [
   {  $currentOp: { } },
   {  $facet: {
      "locked": [
         { $match: { $and: [
            { fsyncLock: { $exists: true } }
         ] } }],
       "unlocked": [
         { $match: { fsyncLock: { $exists: false } } }
       ]
   } },
   {  $project: {
      "fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] },
      "fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] }
   } }
 ] )
[ { fsyncLocked: true }, { fsyncUnlocked: false } ]
4

プライマリコンフィギュレーションサーバーのバックアップ

注意

コンフィギュレーションサーバーをバックアップすると、シャーディングされたクラスターのメタデータがバックアップされます。 すべてが同じデータを保持するため、バックアップは 1 つだけです。 CSRS プライマリ ノードに対してこの手順を実行します。

コンフィギュレーションサーバーのファイルシステム スナップショットを作成するには、「 スナップショットの作成 」の手順に従います。

5

プライマリシャードのバックアップ

「 ファイルシステム スナップショットを使用した自己管理型配置のバックアップと復元 」の手順を使用して、各シャードのプライマリ ノードに対してファイルシステム スナップショットを実行します。

6

クラスターのロック解除

バックアップが完了したら、書き込みを再開できるようにクラスターのロックを解除する必要があります。

クラスターのロックを解除するには、 db.fsyncUnlock()メソッドを使用します。

db.getSibling("admin").fsyncUnlock()

次の集計パイプラインを、コンフィギュレーションサーバーのmongosとプライマリmongodの両方で実行します。 ロックを確認するには、 fysncLockedフィールドがfalseを返し、 fsyncUnlockedフィールドがtrueを返すことを確認します。

db.getSiblingDB("admin").aggregate( [
   {  $currentOp: { } },
   {  $facet: {
      "locked": [
         { $match: { $and: [
            { fsyncLock: { $exists: true } }
         ] } }],
       "unlocked": [
         { $match: { fsyncLock: { $exists: false } } }
       ]
   } },
   { $project: {
      "fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] },
      "fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] }
   } }
 ] )
[ { fsyncLocked: false }, { fsyncUnlocked: true } ]
7

バランサーを再起動する

バランサーを再起動するには、 sh.startBalancer()メソッドを使用します。

sh.startBalancer()

バランサーが実行中であることを確認するには、 sh.getBalancerState()メソッドを使用します。

sh.getBalancerState()
true

バランサーが実行中、このコマンドはtrueを返します。

戻る

シャーディングされたクラスターの復元

次へ

Use Database Dumps