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

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

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

データベースを削除します。<a class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \" class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\"local \"> <path fill=\" \" d=\" \">

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

use local
db.dropDatabase()

フィルタリングされたファイルリストをローカルデータベースに挿入します。

この手順は、名前空間でフィルタリングされたスナップショットから復元する場合にのみ必要です。

各シャードについて、次の名前形式のフィルタリングされたファイル リストを見つけます: <shardRsID>-filteredFileList.txt 。 このファイルには、次の形式の JSON オブジェクトのリストが含まれています。

{
   "filename":"file1",
   "ns":"sampleDb1.sampleCollection1",
   "uuid": "3b241101-e2bb-4255-8caf-4136c566a962"
}

各シャード ファイルの各 JSON オブジェクトを、 localデータベース内の新しいdb.systems.collections_to_restoreコレクションに追加します。 空のnsまたはuuidフィールドを持つエントリは無視できます。 エントリを挿入するときは、 uuidフィールドを タイプUUID()として挿入する必要があります。

フィルタリングされたファイル復元コマンドを実行します。

この手順は、名前空間でフィルタリングされたスナップショットから復元する場合にのみ必要です。

すべてのエントリを挿入した後、次のコマンドを実行します。

use admin
db.runCommand({"_configsvrRunRestore":1})

計画的または完了したシャードホスト名またはレプリカセット名の変更については、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
}

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" } }
)

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

use config
db.shards.find({})

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

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

replication:
  replSetName: myNewCSRSName
sharding:
  clusterRole: configsvr

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

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

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

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

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

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

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

rs.initiate()

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

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

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()はプライマリからのみ実行できます。

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

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

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

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

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

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

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

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>")

データベースを削除します。<a class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \" class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\"local \"> <path fill=\" \" d=\" \">

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

use local
db.dropDatabase()

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

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

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

オプション: 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"}
  }
)

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

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

replication:
  replSetName: myNewShardName
sharding:
  clusterRole: shardsvr

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

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

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

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

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

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

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

rs.initiate()

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

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

シャード レプリカセット内の各レプリカセット ノードについて、そのホストマシン上で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()はプライマリからのみ実行できます。

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

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

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

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

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

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

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

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

   db.removeUser("mySystemUser")