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

自己管理型シャーディングされたクラスターの復元

項目一覧

この手順では、 LVM スナップショットなどの既存のバックアップ スナップショットからシャーディングされたクラスターを復元します。 ソースとターゲットのシャーディングされたクラスターは同じ数のシャードを持つ必要があります。 シャーディングされたクラスターのすべてのコンポーネントの LVM スナップショットの作成については、「ファイルシステム スナップショットを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。

注意

mongodumpとmongorestoreをシャーディングされたクラスターのバックアップ戦略として使用するには、「データベース ダンプを使用した自己管理型シャーディングされたクラスターのバックアップ 」を参照してください。

シャーディングされたクラスターではバックアップと復元に次のいずれかの連携的なプロセスも利用できます。これによりシャード間のトランザクションはアトミック性が継続的に保証されます。

Considerations

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

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

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

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

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

A.（任意）レプリカセットの構成確認

この手順では、デフォルト構成を使用して、コンフィギュレーションサーバー レプリカセット（CSRS）と各シャード レプリカセットの新しいレプリカセットを開始します。 復元された CSRS とシャードに対して別のレプリカセット構成を使用するには、レプリカセットを再構成する必要があります。

ソースクラスターが正常でアクセス可能な場合は、 mongo shell を各レプリカセット内のプライマリ レプリカセット ノードに接続し、 rs.conf()を実行してレプリカ構成ドキュメントを表示します。

ソース シャーディングされたクラスターの 1 つ以上のコンポーネントにアクセスできない場合は、既存の内部ドキュメントを参照して、各シャード レプリカセットとコンフィギュレーションサーバー レプリカセットの構成要件を再構築してください。

B. 復元用のターゲット ホストの準備

ストレージ領域の要件
ターゲット ホスト ハードウェアに、復元されたデータ用の十分なオープン ストレージ領域があることを確認します。 ターゲット ホストに保持する既存のシャーディングされたクラスター データが含まれている場合は、既存データと復元されたデータの両方に十分なストレージ領域があることを確認してください。
LVM の要件
LVM スナップショットの場合は、少なくとも 1 つの LVM 管理ボリュームグループと、抽出されたスナップショットデータ用に十分な空き領域がある論理ボリュームが必要です。
MongoDB のバージョン要件

ターゲット ホストとソース ホストが同じ MongoDB Server バージョンを持っていることを確認します。 ホストマシンで使用可能な MongoDB のバージョンを確認するには、ターミナルまたは shell からmongod --versionを実行します。

インストールに関する詳細なドキュメントについては、「 MongoDB のインストール 」を参照してください。

実行中の MongoDB プロセスのシャットダウン

既存のクラスターに復元する場合は、ターゲット ホストでmongodまたはmongosプロセスをシャットダウンします。

mongosを実行しているホストの場合は、 mongo shell をmongosに接続し、 adminデータベースからdb.shutdownServer()を実行します。

use admin
db.shutdownServer()

mongodを実行しているホストの場合は、 mongo shell をmongodに接続し、 db.hello()を実行します。

  • isWritablePrimaryが false の場合、 mongodはレプリカセットのセカンダリメンバーです。 シャットダウンするには、 adminデータベースからdb.shutdownServer()を実行します。

  • isWritablePrimaryが true の場合、 mongodはレプリカセットのプライマリメンバーです。 最初に 、レプリカセットの セカンダリ ノードを シャットダウンします 。 レプリカセットの他のノードを識別するには、 rs.status()を使用します。

    プライマリは、大多数のノードがオフラインであることを検出すると、自動的に降格します。 ステップダウン後（ db.hello()がisWritablePrimary: falseを返します）、 mongodを安全にシャットダウンできます。

データディレクトリの準備

復元されたデータベース ファイルのターゲット ホスト上にディレクトリを作成します。 mongodを実行するユーザーが、そのディレクトリ内のすべてのファイルとサブフォルダに対する読み取り、書込み (write)、実行権限があることを確認します。

sudo mkdir /path/to/mongodb
sudo chown -R mongodb:mongodb /path/to/mongodb
sudo chmod -R 770 /path/to/mongodb

/path/to/mongodbを、作成したデータディレクトリへのパスに置き換えます。 RHEL / CentOS、Amazon Linux、および SUSE では、デフォルトのユーザー名はmongodです。

ログ ディレクトリの準備

ターゲット ホストにmongodログ ファイルのディレクトリを作成します。 mongodを実行するユーザーが、そのディレクトリ内のすべてのファイルとサブフォルダに対する読み取り、書込み (write)、実行権限があることを確認します。

sudo mkdir /path/to/mongodb/logs
sudo chown -R mongodb:mongodb /path/to/mongodb/logs
sudo chmod -R 770 /path/to/mongodb/logs

/path/to/mongodb/logsを作成したログ ディレクトリへのパスに置き換えます。 RHEL / CentOS、Amazon Linux、および SUSE では、デフォルトのユーザー名はmongodです。

構成ファイルを作成

この手順では、mongod 構成ファイル を使用して を起動することを前提としています。

構成ファイルを希望の場所に作成します。 mongodを実行するユーザーに、構成ファイルに対する読み取りおよび書込み権限があるようにします。

sudo touch /path/to/mongod.conf
sudo chown mongodb:mongodb /path/to/mongodb/mongod.conf
sudo chmod 644 /path/to/mongodb/mongod.conf

RHEL / CentOS、Amazon Linux、および SUSE では、デフォルトのユーザー名はmongodです。

お好みのテキストエディタで構成ファイルを開き、配置に応じて を変更します。 または、 mongodの元の構成ファイルにアクセスできる場合は、それをターゲット ホスト上の希望する場所にコピーします。

重要

構成ファイルに次の設定が含まれていることを検証します。

  • storage.dbPath には、目的のデータ ディレクトリへのパスを設定する必要があります。

  • systemLog.path は、使用するログ ディレクトリへのパスに設定する必要があります

  • net.bindIp には、ホスト マシンの IP アドレスを含める必要があります。

  • replication.replSetName には、特定のレプリカセット内の各ノードにわたって同じ 値があります。

  • sharding.clusterRole には、特定のレプリカセット内の各ノードにわたって同じ 値があります。

  • また、スナップショットで指定されたのと同じ起動オプションを新しい配置で指定する必要があります。

C. コンフィギュレーションサーバーのレプリカセットを復元する

1

CSRS プライマリmongod データファイルを復元します。

ご希望のバックアップ メソッドに対応するタブを選択します。

  1. LVMスナップショットをターゲット ホスト マシンにマウントします。 LVM スナップショットをマウントするための具体的な手順は、LVM 構成によって異なります。

    次の例では、 「 ファイルシステム スナップショットを使用した自己管理型配置のバックアップと復元 」 手順 の スナップショットの作成 ステップを使用して作成された LVM スナップショットを前提としています。

    lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
    gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
    mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb

    この例は、可能なすべての LVM 構成に適用されるわけではありません。 LVM 復元に関する詳細なガイダンスについては、システムの LVM ドキュメントを参照してください。

  2. スナップショット マウントからmongodデータファイルを B. Prepare the Target Host for Restorationで作成されたデータ ディレクトリにコピーします。

    cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb

    -aオプションは、フォルダーとファイルの権限を保持しながら、ソース パスの内容を宛先パスに再帰的にコピーします。

  3. 次の構成ファイル設定をコメントアウトするか省略します。

    #replication
    #  replSetName: myCSRSName
    #sharding
    #  clusterRole: configsvr

    構成ファイルを使用してmongodを起動するには、構成ファイルへの完全パスを指定して、コマンドラインで--configオプションを指定します。

    mongod --config /path/to/mongodb/mongod.conf

    mongodがシステム サービスとして実行するように構成されている場合は、システム サービス マネージャーに推奨されるプロセスを使用して起動します。

    mongodが起動したら、 mongo shell を使用して接続します。

  1. ホスト上で選択したバックアップに保存されているデータファイルにアクセスできるようにします。 これには、バックアップ ボリュームをマウントする、ソフトウェア ユーティリティでバックアップを開く、または別のツールを使用してデータをディスクに抽出する必要がある場合があります。 バックアップに含まれるデータにアクセスする手順については、ご希望のバックアップ ツールのドキュメントを参照してください。

  2. バックアップ データのロケーションからmongodデータファイルをB. Prepare the Target Host for Restorationで作成されたデータ ディレクトリにコピーします。

    cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb

    -aオプションは、フォルダーとファイルの権限を保持しながら、ソース パスの内容を宛先パスに再帰的にコピーします。

  3. 次の構成ファイル設定をコメントアウトするか省略します。

    #replication
    #  replSetName: myCSRSName
    #sharding
    #  clusterRole: configsvr

  4. 構成ファイルを使用してmongodを起動するには、構成ファイルへの完全パスを指定して、コマンドラインで--configオプションを指定します。

    mongod --config /path/to/mongodb/mongod.conf

    注意

    Cloud ManagerまたはMongoDB Ops Managerのみ

    Cloud ManagerまたはMongoDB Ops Managerバックアップの手動復元を実行する場合は、起動前に disableLogicalSessionCacheRefresh サーバー パラメータを指定する必要があります。

    mongod --config /path/to/mongodb/mongod.conf \
      --setParameter disableLogicalSessionCacheRefresh=true

    mongodがシステム サービスとして実行するように構成されている場合は、システム サービス マネージャーに推奨されるプロセスを使用して起動します。

    mongodが起動したら、 mongo shell を使用して接続します。

2

localデータベースを削除します。

db.dropDatabase()を使用してlocalデータベースを削除します。

use local
db.dropDatabase()
3

計画的または完了したシャードホスト名またはレプリカセット名の変更については、config.shards のメタデータを更新します。

次のすべてが当てはまる場合は、この手順をスキップできます。

  • この手順中に、シャード ノード ホスト マシンのホスト名が または 変更されることはありません。

  • この手順中にシャード レプリカセット名が または 変更されることはありません。

find()構成データベース のshards コレクションに対して次の メソッドを発行します。<shardName>をシャード名に置き換えます。 デフォルトでは、シャード名はそのレプリカセット名です。 addShardコマンドを使用してシャードを追加し、カスタムnameを指定した場合は、そのnameに<shardName>を指定する必要があります。

use config
db.shards.find( { "_id" : "<shardName>" } )

この操作は、次のようなドキュメントを返します。

{
   "_id" : "shard1",
   "host" : "myShardName/alpha.example.net:27018,beta.example.net:27018,charlie.example.net:27018",
   "state" : 1
}

重要

_id値は、対応するシャード上の_id : "shardIdentity"ドキュメント内のshardName値と一致する必要があります。 この手順の後半でシャードを復元するときに、 shardsの_idフィールドがシャードのshardName値と一致していることを検証します。

updateOne()メソッドを使用してhosts string を更新し、シャードの予定されたレプリカセット名とホスト名リストを反映します。 たとえば、次の操作は、"_id" : "shard1" を使用してシャードの host 接続stringを更新します。

db.shards.updateOne(
  { "_id" : "shard1" },
  { $set : { "host" : "myNewShardName/repl1.example.net:27018,repl2.example.net:27018,repl3.example.net:27018" } }
)

すべてのシャード メタデータが、クラスター内の各シャードに計画されているレプリカセット名とホスト名リストを正確に反映するまで、このプロセスを繰り返します。

注意

シャード名がわからない場合は、空のフィルタードキュメント を使用してfind() shardsコレクションに対して{} メソッドを発行します。

use config
db.shards.find({})

結果セット内の各ドキュメントは、クラスター内の 1 つのシャードを表します。 各ドキュメントについて、対象のシャードに一致する接続string 、つまり一致するレプリカセット名とノードのホスト名リストの host フィールドを確認します。 <shardName>の代わりにそのドキュメントの_idを使用します。

4

mongodを新しい単一ノードレプリカセットとして再起動します。

をシャットダウンし mongodます。以下の構成ファイルオプションのコメントを解除するか、または追加します。

replication
  replSetName: myNewCSRSName
sharding
  clusterRole: configsvr

レプリカセット名を変更する場合は、続行する前に、 replSetNameフィールドを新しい名前で更新する必要があります。

更新された構成ファイルを使用してmongodを起動します。

mongod --config /path/to/mongodb/mongod.conf

mongodがシステム サービスとして実行するように構成されている場合は、システム サービス マネージャーに推奨されるプロセスを使用して起動します。

mongodが起動したら、 mongo shell を使用して接続します。

5

新しいレプリカセットを開始します。

デフォルト設定でrs.initiate()を使用してレプリカセットを開始します。

rs.initiate()

操作が完了したら、 rs.status()を使用してノードがプライマリになったことを確認します。

6

レプリカセット ノードを追加します。

CSRS 内の各レプリカセット ノードごとに、ホストマシン上でmongodを起動します。 クラスターの残りのすべてのノードを正常に起動したら、 mongo shell をプライマリ レプリカセット ノードに接続します。 プライマリから、 rs.add()メソッドを使用してレプリカセットの各ノードを追加します。 プレフィックスとしてレプリカセット名を含め、その後にノードのmongodプロセスのホスト名とポートを含めます。

rs.add("config2.example.net:27019")
rs.add("config3.example.net:27019")

特定のレプリカmember 構成設定を持つノードを追加する場合は、ノードのホスト名と配置に必要な 設定を定義するドキュメントをrs.add() membersに渡すことができます。

rs.add(
 {
   "host" : "config2.example.net:27019",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

新しい各メンバーは、プライマリに追いつくために最初の同期を実行します。 同期するデータ量、ネットワークのトポロジーと健全性、各ホスト マシンの電源などの要因によっては、最初の同期が完了するまでに長時間かかる場合があります。

ノードを追加するときに、レプリカセットによって新しいプライマリが選択される場合があります。 どのノードが現在のプライマリであるかを識別するには、 rs.status()を使用します。 rs.add()はプライマリからのみ実行できます。

7

追加で必要なレプリケーション設定が必要な場合は、構成します。

rs.reconfig()メソッドは、パラメータとして渡された構成ドキュメントに基づいてレプリカセット構成を更新します。 レプリカセットのプライマリ ノードに対してreconfig()を実行する必要があります。

ステップA. Review Replica Set Configurationsで識別されたレプリカセットの元の構成ファイル出力を参照し、必要に応じて設定を適用します。

D. 各シャード レプリカセットを復元する

1

シャード プライマリmongod データファイルを復元します。

ご希望のバックアップ メソッドに対応するタブを選択します。

  1. LVMスナップショットをターゲット ホスト マシンにマウントします。 LVM スナップショットをマウントするための具体的な手順は、LVM 構成によって異なります。

    次の例では、 「 ファイルシステム スナップショットを使用した自己管理型配置のバックアップと復元 」 手順 の スナップショットの作成 ステップを使用して作成された LVM スナップショットを前提としています。

    lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
    gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
    mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb

    この例は、可能なすべての LVM 構成に適用されるわけではありません。 LVM 復元に関する詳細なガイダンスについては、システムの LVM ドキュメントを参照してください。

  2. スナップショット マウントからmongodデータファイルをB. Prepare the Target Host for Restorationで作成されたデータ ディレクトリにコピーします。

    cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb

    -aオプションは、フォルダーとファイルの権限を保持しながら、ソース パスの内容を宛先パスに再帰的にコピーします。

  3. 次の構成ファイル設定をコメントアウトするか省略します。

    #replication
    #  replSetName: myShardName
    #sharding
    #  clusterRole: shardsvr

    構成ファイルを使用してmongodを起動するには、構成ファイルへの完全パスを指定して、コマンドラインで--configオプションを指定します。

    mongod --config /path/to/mongodb/mongod.conf

    mongodがシステム サービスとして実行するように構成されている場合は、システム サービス マネージャーに推奨されるプロセスを使用して起動します。

    mongodが起動したら、 mongo shell を使用して接続します。

  1. ホスト上で選択したバックアップに保存されているデータファイルにアクセスできるようにします。 これには、バックアップ ボリュームをマウントする、ソフトウェア ユーティリティでバックアップを開く、または別のツールを使用してデータをディスクに抽出する必要がある場合があります。 バックアップに含まれるデータにアクセスする手順については、ご希望のバックアップ ツールのドキュメントを参照してください。

  2. バックアップ データのロケーションからmongodデータファイルをB. Prepare the Target Host for Restorationで作成されたデータ ディレクトリにコピーします。

    cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb

    -aオプションは、フォルダーとファイルの権限を保持しながら、ソース パスの内容を宛先パスに再帰的にコピーします。

  3. 次の構成ファイル設定をコメントアウトするか省略します。

    #replication
    #  replSetName: myShardName
    #sharding
    #  clusterRole: shardsvr

  4. 構成ファイルを使用してmongodを起動するには、構成ファイルへの完全パスを指定して、コマンドラインで--configオプションを指定します。

    mongod --config /path/to/mongodb/mongod.conf

    注意

    Cloud ManagerまたはMongoDB Ops Managerのみ

    Cloud ManagerまたはMongoDB Ops Managerバックアップの手動復元を実行する場合は、起動前に disableLogicalSessionCacheRefresh サーバー パラメータを指定する必要があります。

    mongod --config /path/to/mongodb/mongod.conf \
      --setParameter disableLogicalSessionCacheRefresh=true

    mongodがシステム サービスとして実行するように構成されている場合は、システム サービス マネージャーに推奨されるプロセスを使用して起動します。

    mongodが起動したら、 mongo shell を使用して接続します。

2

__systemロールを持つ一時ユーザーを作成します。

この手順では、 admin.system.versionコレクション内のドキュメントを変更します。 認証を強制するクラスターの場合、このコレクションを変更する権限は__systemロールのみに付与されます。 クラスターが認証を強制しない場合は、この手順をスキップできます。

警告

__systemロールの所有者は、データベース内の任意のオブジェクトに対して任意のアクションを実行することができます。 この手順には、このステップで作成された ユーザーを削除するための手順が含まれています。 この手順の範囲外で、このユーザーをアクティブのままにしないでください。

指定されたホストのみが特権ユーザーとして認証できるように、 clientSource認証制限を構成してこのユーザーを作成することを検討してください。

  1. adminデータベースでのuserAdminロール、またはuserAdminAnyDatabaseロールを持つユーザーとして認証します。

    use admin
    db.auth("myUserAdmin","mySecurePassword")

  2. __systemロールを持つユーザーを作成します。

    db.createUser(
      {
        user: "mySystemUser",
        pwd: "<replaceMeWithAStrongPassword>",
        roles: [ "__system" ]
      }
    )

    パスワードは、システムのセキュリティを確保し、悪意のあるアクセスを防止または遅延させるために、ランダムで長く、複雑なものにする必要があります。

  3. 特権ユーザーとして認証します。

    db.auth("mySystemUser","<replaceMeWithAStrongPassword>")
3

localデータベースを削除します。

db.dropDatabase()を使用してlocalデータベースを削除します。

use local
db.dropDatabase()
4

minOpTimeRecoveryドキュメントをadmin.system.versions コレクションから削除します。

シャーディング内部を更新するには、deleteOne() データベースのsystem.version コレクションに対して次のadmin メソッドを発行します。

use admin
db.system.version.deleteOne( { _id: "minOpTimeRecovery" } )

注意

system.versionコレクションは内部のシステム コレクションです。 このような特定の指示が与えられた場合にのみ、 を変更する必要があります。

5

オプション: CSRS ホスト名またはレプリカセット名が変更された場合は、各シャードの ID ドキュメントでシャード メタデータを更新します。

次のすべてが当てはまる場合は、この手順をスキップできます。

  • この手順では、CSRS ホストのホスト名は変更されませんでした。

  • この手順では、CSRS レプリカセット名は変更されませんでした。

admin データベースのsystem.versionコレクションには、 CSRS 接続stringなど、シャードに関連するメタデータが含まれています。 CSRS の復元中に CSRS 名またはノードのホスト名が変更された場合は、このメタデータを更新する必要があります。

次のfind()メソッドをadminデータベース内のsystem.versionコレクションに対して発行します。

use admin
db.system.version.find( {"_id" : "shardIdentity" } )

find()メソッドは、次のようなドキュメントを返します。

{
  "_id" : "shardIdentity",
  "clusterId" : ObjectId("2bba123c6eeedcd192b19024"),
  "shardName" : "shard1",
  "configsvrConnectionString" : "myCSRSName/alpha.example.net:27019,beta.example.net:27019,charlie.example.net:27019" }

次のupdateOne()メソッドは、host stringが最新の CSRS 接続stringを表すようにドキュメントを更新します。

db.system.version.updateOne(
  { "_id" : "shardIdentity" },
  { $set :
    { "configsvrConnectionString" : "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"}
  }
)

重要

shardName値は、CSRS のshardsコレクション内の_id値と一致する必要があります。 CSRS のメタデータがシャードのメタデータと一致することを検証します。 CSRS メタデータを表示する手順については、この手順のC. Restore Config Server Replica Set部分のサブステップ3を参照してください。

6

mongodを新しい単一ノードレプリカセットとして再起動します。

をシャットダウンし mongodます。以下の構成ファイルオプションのコメントを解除するか、または追加します。

replication
  replSetName: myNewShardName
sharding
  clusterRole: shardsvr

レプリカセット名を変更する場合は、続行する前に、 replSetNameフィールドを新しい名前で更新する必要があります。

更新された構成ファイルを使用してmongodを起動します。

mongod --config /path/to/mongodb/mongod.conf

mongodがシステム サービスとして実行するように構成されている場合は、システム サービス マネージャーに推奨されるプロセスを使用して起動します。

mongodが起動したら、 mongo shell を使用して接続します。

7

新しいレプリカセットを開始します。

デフォルト設定でrs.initiate()を使用してレプリカセットを開始します。

rs.initiate()

操作が完了したら、 rs.status()を使用してノードがプライマリになったことを確認します。

8

レプリカセット ノードを追加します。

シャード レプリカセット内の各レプリカセット ノードについて、そのホストマシン上でmongodを起動します。 クラスターの残りのすべてのノードを正常に起動したら、 mongo shell をプライマリ レプリカセット ノードに接続します。 プライマリから、 rs.add()メソッドを使用してレプリカセットの各ノードを追加します。 プレフィックスとしてレプリカセット名を含め、その後にノードのmongodプロセスのホスト名とポートを含めます。

rs.add("repl2.example.net:27018")
rs.add("repl3.example.net:27018")

特定のレプリカmember 構成設定を持つノードを追加する場合は、ノードのホスト名と配置に必要な 設定を定義するドキュメントをrs.add() membersに渡すことができます。

rs.add(
 {
   "host" : "repl2.example.net:27018",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

新しい各メンバーは、プライマリに追いつくために最初の同期を実行します。 同期するデータ量、ネットワークのトポロジーと健全性、各ホスト マシンの電源などの要因によっては、最初の同期が完了するまでに長時間かかる場合があります。

ノードを追加するときに、レプリカセットによって新しいプライマリが選択される場合があります。 どのノードが現在のプライマリであるかを識別するには、 rs.status()を使用します。 rs.add()はプライマリからのみ実行できます。

9

追加で必要なレプリケーション設定が必要な場合は、構成します。

rs.reconfig()メソッドは、パラメータとして渡された構成ドキュメントに基づいてレプリカセット構成を更新します。 レプリカセットのプライマリ ノードに対してreconfig()を実行する必要があります。

ステップA. Review Replica Set Configurationsで識別されたレプリカセットの元の構成ファイル出力を参照し、必要に応じて設定を適用します。

10

一時特権ユーザーを削除します。

認証が強制されるクラスターの場合は、この手順の前半で作成した特権ユーザーを削除します。

  1. adminデータベースでのuserAdminロール、またはuserAdminAnyDatabaseロールを持つユーザーとして認証します。

    use admin
    db.auth("myUserAdmin","mySecurePassword")

  2. 特権ユーザーを削除します。

    db.removeUser("mySystemUser")

E. 各 の再起動 mongos

クラスター内の各mongosを再起動します。

mongos --config /path/to/config/mongos.conf

配置に必要な他のすべてのコマンドライン オプションを含めます。

CSRS レプリカセット名またはノードのホスト名が変更された場合は、更新された構成サーバー接続mongos を使用してsharding.configDB 構成ファイルの設定string を更新します。

sharding:
  configDB: "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"

F. クラスターのアクセス可能性を検証する

mongo shell をクラスターのmongosプロセスの 1 つに接続します。 クラスター全体のステータスを確認するには、 sh.status()を使用します。 sh.status()がバランサーが実行中でないことを示す場合は、 sh.startBalancer()を使用してバランサーを再起動します。 [1]

すべてのシャードがアクセス可能で通信していることを確認するには、一時的にシャーディングされたコレクションにテスト データを挿入します。 クラスター内の各シャード間でデータが分割され、移行されていることを確認します。 mongo shell を各シャード プライマリに接続し、 db.collection.find()を使用して、データが期待どおりにシャーディングされたことを検証できます。

[1] MongoDB 6.0.3 以降では、自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。 詳細については、「バランシング ポリシーの変更 」を参照してください。 MongoDB バージョン 6.0.3 より前では、 sh.startBalancer()によってシャーディングされたクラスターの自動分割も有効になります。

戻る

バックアップのスケジュール

次へ

スタンドアロンのリカバリ