自己管理型レプリカセットのシャーディングされたクラスターへの変換

項目一覧

Overview

Considerations
前提条件
手順
詳細

Overview

このチュートリアルでは、単一の 3 メンバーのレプリカセットを 2 つのシャードを持つシャーディングされたクラスターに変換します。各シャードは、独立した 3 つのメンバーのレプリカセットです。このチュートリアルは MongoDB 6.0に固有です。その他のバージョンの MongoDB については、対応するバージョンの MongoDB マニュアルを参照してください。

でホストされている配置の UI で、シャーディングされたクラスターに変換 MongoDB Atlasできます。

Considerations

これらの手順の個々の手順で、ダウンタイムがいつ発生するかを示します。

重要

これらの手順によって配置のダウンタイムが発生します。

前提条件

このチュートリアルでは、 mongosに 1 つのサーバーと、最初のレプリカセット、2 番目のレプリカセット、コンフィギュレーションサーバーのレプリカセットに対してそれぞれ 3 つのサーバーを使用します。

各サーバーには、システム内の解決可能なドメイン、ホスト名、または IP アドレスが必要です。

このチュートリアルでは、デフォルトのデータディレクトリ（例: /data/dbと/data/configdb ）。適切な権限を持つ適切なディレクトリを作成します。別のパスを使用するには、「自己管理型構成ファイルオプション」を参照してください。

手順

レプリカセットから既存のユーザーとロールを取得する

既存のユーザーとロールを取得するには、mongodump を実行します。

mongodump -d=admin --out=adminDump -u <adminUser> -p <password> --host <replicaSetURI> --dumpDbUsersAndRoles

コンフィギュレーションサーバーのレプリカセットを配置する

コンフィギュレーションサーバーに 3 つのノードのレプリカセットを配置します。この例では、コンフィギュレーションサーバーは次のホストを使用します。

mongodb7.example.net
mongodb8.example.net
mongodb9.example.net

コンフィギュレーションサーバーを設定する

各コンフィギュレーションサーバーホストで mongod インスタンスを構成します。各 mongod インスタンスの構成ファイルで次のオプションを指定します。

オプション	値
`replication.replSetName`	`configReplSet`
`sharding.clusterRole`	`configsvr`
`net.bindIp`	`localhost`、その後に `mongod` がクライアント接続をリッスンするその他のホスト名が続きます。

replication:
  replSetName: configReplSet
sharding:
  clusterRole: configsvr
net:
  bindIp: localhost,<hostname(s)>

配置に応じて、オプションを追加します。

コンフィギュレーションサーバーを起動する
指定した構成で mongod を配置します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```
コンフィギュレーションサーバーは、デフォルトのデータディレクトリ /data/configdb とデフォルトのポート 27019 を使用します。
複数のコンフィギュレーションサーバーうちいずれかに接続します。
mongosh を使用して、構成サーバーの 1 つに接続します。以下に例を挙げます。
```
mongosh "mongodb://mongodb7.example.net:27019"
```

コンフィギュレーションサーバーのレプリカセットを開始します。

レプリカセットを開始するには、rs.initiate() を実行します。

rs.initiate( {
   _id: "configReplSet",
   configsvr: true,
   members: [
      { _id: 0, host: "mongodb7.example.net:27019" },
      { _id: 1, host: "mongodb8.example.net:27019" },
      { _id: 2, host: "mongodb9.example.net:27019" }
   ]
} )

上記のコマンドは、localhost 例外を使用して、認証なしで管理アクションを実行します。

重要

必ず 1 件のmongodインスタンス上でのみrs.initiate()を実行します。

既存のユーザーとロールを新しい設定に復元する

mongodump を実行したときに取得した既存のユーザーとロールを復元します。

mongorestore ./adminDump --nsInclude "admin.*" --host <configPrimaryURI>

上記のコマンドは、localhost 例外を使用して、認証なしで管理アクションを実行します。

このコマンドを実行した場合の出力は次のようになります。

0 document(s) restored successfully

このメッセージは問題を示していません。この出力は、ユーザーとロール以外の 0 ドキュメントが復元されたことを意味します。

コンフィギュレーションサーバーのレプリカセットを確保する

コンフィギュレーションサーバーのレプリカセットを再構成して再起動します。

コンフィギュレーションサーバーを再構成する

認証メカニズムのタブを選択します。

次の各ホストで mongod インスタンスを再起動します。

mongodb7.example.net
mongodb8.example.net
mongodb9.example.net

各 mongod インスタンスの構成ファイルで次のオプションを指定します。

オプション	値
`security.keyFile`	最初のレプリカセット用のキーファイルへのパス

security:
   keyFile: <PATH_TO_KEYFILE>
replication:
   replSetName: configReplSet
sharding:
   clusterRole: configsvr
net:
   bindIp: localhost,<hostname(s)>

配置に応じて、オプションを追加します。

次の各ホストで mongod インスタンスを再起動します。

mongodb7.example.net
mongodb8.example.net
mongodb9.example.net

すでに構成したオプションに加えて、各 mongod インスタンスの構成ファイルで次のオプションを指定します。

オプション	値
`security.clusterAuthMode`	`x509`
`net.tls.mode`	`requireTLS`
`net.tls.certificateKeyFile`	TLS 証明書とキーの両方を含む `.pem` ファイルへの絶対パス。
`net.tls.CAFile`	認証局からのルート証明書チェーンを含む `.pem` ファイルへの絶対パス
`net.bindIp`	`localhost`、その後に `mongod` がクライアント接続をリッスンするその他のホスト名が続きます。警告非ローカルホスト（例: （一般にアクセス可能な）IP アドレスを使用して、クラスターを不正アクセスから保護していることを確認します。セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティチェックリスト」を参照してください。最低限、認証を有効化し、ネットワークインフラストラクチャの強化を検討してください。

sharding:
   clusterRole: configsvr
replication:
   replSetName: configReplSet
security:
   clusterAuthMode: x509
net:
   tls:
      mode: requireTLS
      certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
      CAFile: <CA_FILE>
   bindIp: localhost,<hostname(s)>

TLS 証明書キーファイルがパスワードで暗号化されている場合は、net.tls.certificateKeyFilePassword など、配置に適切な追加のオプションを含めます。

MongoDB を再起動する
指定した構成で mongod を再起動します。
```
mongod --config <PATH_TO_CONFIG_FILE> --shutdown
mongod --config <PATH_TO_CONFIG_FILE>
```

次のコードを配置する: `mongos`

mongos は、クライアントアプリケーションとシャーディングされたクラスター間のインターフェースを提供します。

mongos の設定ファイルを作成します。

mongos 構成ファイルで次のオプションを指定します。

オプション	値
`sharding.configDB`	`configReplSet`、その後にスラッシュ `/` と、コンフィギュレーションサーバーのホスト名とポートの少なくとも 1 つが続きます。
`security.keyFile`	最初のレプリカセット用のキーファイルへのパス
`net.bindIp`	`localhost`、その後に `mongos` がクライアント接続をリッスンするその他のホスト名が続きます。

sharding:
   configDB: configReplSet/mongodb7.example.net:27019,mongodb8.example.net:27019,mongodb9.example.net:27019
security:
   keyFile: <PATH_TO_KEYFILE>
net:
   bindIp: localhost,<hostname(s)>

配置に応じて、オプションを追加します。

mongos 構成ファイルで次のオプションを指定します。

オプション	値
`sharding.configDB`	`configReplSet`、その後にスラッシュ `/` と、コンフィギュレーションサーバーのホスト名とポートの少なくとも 1 つが続きます。
`security.clusterAuthMode`	`x509`
`net.tls.mode`	`requireTLS`
`net.tls.certificateKeyFile`	TLS 証明書とキーの両方を含む `.pem` ファイルへの絶対パス。
`net.tls.CAFile`	認証局からのルート証明書チェーンを含む `.pem` ファイルへの絶対パス
`net.bindIp`	`localhost`、その後に `mongos` がクライアント接続をリッスンするその他のホスト名が続きます。

sharding:
   configDB: configReplSet/mongodb7.example.net:27019,mongodb8.example.net:27019,mongodb9.example.net:27019
security:
   clusterAuthMode: x509
net:
   tls:
      mode: requireTLS
      certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
      CAFile: <CA_FILE>
   bindIp: localhost,<hostname(s)>

配置に適切な追加のオプションを含めます。

mongos を配置します。
指定した構成で mongos を配置します。
```
mongos --config <PATH_TO_CONFIG_FILE>
```

初期レプリカセットをシャードとして再起動する

この例では、最初のレプリカセットは 3 つのノードからなるレプリカセットです。この手順では、初期レプリカセットを更新して、シャーディングされたクラスターにシャードとして追加できるようにします。

レプリカセットは、次のホストで実行されます。

mongodb0.example.net:27017
mongodb1.example.net:27017
mongodb2.example.net:27017

シャーディングされたクラスターの場合、シャード内の各 mongod インスタンスのロールを shardsvr に設定する必要があります。サーバーの役割を指定するには、mongod 構成ファイルで sharding.clusterRole 設定を設定します。

注意

shardsvr ロールを持つ mongod インスタンスのデフォルトポートは 27018 です。別のポートを使用するには、net.port 設定を指定します。

初期レプリカセットのノードに接続します。
mongosh を使用して、初期レプリカセットのノードの 1 つに接続します。
mongosh "mongodb://<username>@mongodb0.example.net:27017"
配置で x.509 認証を使用する場合は、次の mongosh オプションを指定します。
--tls
--tlsCAFile
--tlsCertificateKeyFile
以下に例を挙げます。
mongosh "mongodb://<username>@mongodb0.example.net:27017" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
レプリカセットのプライマリとセカンダリを決定します。
プライマリとセカンダリを決定するには、rs.status() を実行します。
```
rs.status()
```
コマンド出力の replSetGetStatus.members[n].stateStr フィールドは、どのノードがプライマリで、どのノードがセカンダリであるかを示します。

--shardsvr オプションを使用してセカンダリを再起動します。

警告

この手順では、レプリカセットのセカンダリに接続されたアプリケーションのダウンタイムが必要になります。

セカンダリを再起動した後、そのセカンダリに接続されているすべてのアプリケーションは、初期レプリカセットをシャードとして追加するの手順を実行するまで、 CannotVerifyAndSignLogicalTimeエラーを返します。

アプリケーションを再起動して、CannotVerifyAndSignLogicalTime エラーを受信しないようにすることもできます。

セカンダリに接続します。
mongosh を使用して、セカンダリの 1 つに接続します。
```
mongosh "mongodb://<username>@<host>:<port>"
```
セカンダリをシャットダウンします。
次のコマンドを実行します。
```
use admin
db.shutdownServer()
```
セカンダリの構成ファイルを編集します。
次のように、セカンダリの構成ファイルで sharding.clusterRole を shardsvr に設定します。
```
security:
   keyFile: <PATH_TO_KEYFILE>
replication:
  replSetName: rs0
sharding:
   clusterRole: shardsvr
net:
   port: 27017
   bindIp: localhost,<hostname(s)>
```
配置に応じて、オプションを追加します。
セカンダリをシャードサーバーとして再起動します。
セカンダリを含むホストで次のコマンドを実行します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```
他のセカンダリに対してもシャットダウンと再起動の手順を繰り返します。

セカンダリに接続します。
mongosh を使用して、セカンダリの 1 つに接続します。
配置で x.509 認証を使用する場合は、次の mongosh オプションを指定します。
```
mongosh "mongodb://<username>@<host>:<port>" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
```
セカンダリをシャットダウンします。
次のコマンドを実行します。
```
use admin
db.shutdownServer()
```

セカンダリの構成ファイルを編集します。

次のように、セカンダリの構成ファイルで sharding.clusterRole を shardsvr に設定します。

replication:
   replSetName: rs0
sharding:
   clusterRole: shardsvr
security:
   clusterAuthMode: x509
net:
   port: 27017
   tls:
      mode: requireTLS
      certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
      CAFile: <CA_FILE>
   bindIp: localhost,<hostname(s)>

TLS 証明書キーファイルがパスワードで暗号化されている場合は、net.tls.certificateKeyFilePassword など、配置に適切な追加のオプションを含めます。

セカンダリをシャードサーバーとして再起動します。
セカンダリを含むホストで次のコマンドを実行します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```
他のセカンダリに対してもシャットダウンと再起動の手順を繰り返します。

`--shardsvr`オプションを使用してプライマリを再起動します。

警告

この手順では、レプリカセットのプライマリに接続されているアプリケーションのダウンタイムが必要になります。

プライマリを再起動した後、初期レプリカセットをシャードとして追加するの手順を実行するまで、プライマリに接続されているすべてのアプリケーションはCannotVerifyAndSignLogicalTimeエラーを返します。

アプリケーションを再起動して、CannotVerifyAndSignLogicalTime エラーを受信しないようにすることもできます。

プライマリに接続します。
プライマリに接続するには、mongosh を使用します。
```
mongosh "mongodb://<username>@<host>:<port>"
```
プライマリを降格します。
次のコマンドを実行します:
```
rs.stepDown()
```
降格の完了を検証します。
rs.status() を実行して、接続しているノードが降格してセカンダリになったことを確認します。
```
rs.status()
```
以前のプライマリをシャットダウンします。
次のコマンドを実行します。
```
use admin
db.shutdownServer()
```
シャットダウンが完了するまで待機します。
プライマリの構成ファイルを編集します。
プライマリの構成ファイルで、sharding.clusterRole を shardsvr に設定します。
```
security:
   keyFile: <PATH_TO_KEYFILE>
replication:
   replSetName: rs0
sharding:
   clusterRole: shardsvr
net:
   port: 27017
   bindIp: localhost,<hostname(s)>
```
配置に応じて、オプションを追加します。
プライマリをシャードサーバーとして再起動します。
プライマリを含むホストで次のコマンドを実行します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```

プライマリに接続します。
mongosh を使用して、セカンダリの 1 つに接続します。
配置で x.509 認証を使用する場合は、次の mongosh オプションを指定します。
配置で x.509 認証を使用する場合は、次の mongosh オプションを指定します。
```
mongosh "mongodb://<username>@<host>:<port>" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
```
プライマリを降格します。
次のコマンドを実行します:
```
rs.stepDown()
```
降格の完了を検証します。
rs.status() を実行して、接続しているノードが降格してセカンダリになったことを確認します。
```
rs.status()
```
以前のプライマリをシャットダウンします。
次のコマンドを実行します。
```
use admin
db.shutdownServer()
```
シャットダウンが完了するまで待機します。

プライマリの構成ファイルを編集します。

プライマリの構成ファイルで、sharding.clusterRole を shardsvr に設定します。

replication:
   replSetName: rs0
sharding:
   clusterRole: shardsvr
security:
   clusterAuthMode: x509
net:
   port: 27017
   tls:
      mode: requireTLS
      certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
      CAFile: <CA_FILE>
   bindIp: localhost,<hostname(s)>

TLS 証明書キーファイルがパスワードで暗号化されている場合は、net.tls.certificateKeyFilePassword など、配置に適切な追加のオプションを含めます。

プライマリをシャードサーバーとして再起動します。
プライマリを含むホストで次のコマンドを実行します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```

初期レプリカセットをシャードとして追加する

初期レプリカセット（rs0）をシャードに変換した後、それをシャーディングされたクラスターに追加します。

クラスターの管理ユーザーとして mongos に接続します。
mongos インスタンスはホスト mongodb6.example.net 上で実行されています。
mongosh を mongos に接続するには、次のコマンドを実行します。
mongosh "mongodb://admin01@mongodb6.example.net:27017"
配置で x.509 認証を使用する場合は、次の mongosh オプションを指定します。
配置で x.509 認証を使用する場合は、次の mongosh オプションを指定します。
--tls
--tlsCAFile
--tlsCertificateKeyFile
mongosh "mongodb://admin01@mongodb6.example.net:27017" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
このコマンドは、シャーディングされたクラスターで作成した admin01 ユーザーとして認証します。コマンドを入力した後、ユーザーのパスワードを入力します。
シャードを追加します。
クラスターにシャードを追加するには、sh.addShard() メソッドを実行します。
```
sh.addShard( "rs0/mongodb0.example.net:27017,mongodb1.example.net:27017,mongodb2.example.net:27017" )
```
警告
新しいシャードがアクティブになると、mongosh と他のクライアントは常に mongos インスタンスに接続する必要があります。mongod インスタンスに直接接続しないでください。クライアントがシャードに直接接続すると、データまたはメタデータの不整合が発生する可能性があります。

アプリケーション接続文字列を更新する

最初のシャードをクラスターに追加した後、アプリケーションで使用される接続文字列を、シャーディングされたクラスターの接続文字列に更新します。それから、アプリケーションを再起動します。

2 つ目のレプリカセットを配置する

rs1 という新しいレプリカセットを配置します。レプリカセット rs1 のノードは次のホスト上にあります。

mongodb3.example.net
mongodb4.example.net
mongodb5.example.net

レプリカセットの各ノードを起動します。

レプリカセットの各 mongod インスタンスに対して、次のオプションを含む構成ファイルを作成します。

オプション	値
`security.keyFile`	最初のレプリカセット用のキーファイルへのパス
`replication.replSetName`	`rs1`
`sharding.clusterRole`	`shardsvr`
`net.bindIp`	`localhost`、その後に `mongod` がクライアント接続をリッスンするその他のホスト名が続きます。

security:
   keyFile: <PATH_TO_KEYFILE>
replication:
   replSetName: rs1
sharding:
   clusterRole: shardsvr
net:
   bindIp: localhost,<hostname(s)>

配置に応じて、オプションを追加します。

各ノードに対して、次のオプションで mongod を開始します。

オプション	値
`replication.replSetName`	`rs1`
`sharding.clusterRole`	`shardsvr`
`security.clusterAuthMode`	`x509`
`net.tls.mode`	`requireTLS`
`net.tls.certificateKeyFile`	TLS 証明書とキーの両方を含む `.pem` ファイルへの絶対パス。
`net.tls.CAFile`	認証局からのルート証明書チェーンを含む `.pem` ファイルへの絶対パス
`net.bindIp`	`localhost`、その後に `mongod` がクライアント接続をリッスンするその他のホスト名が続きます。

replication:
   replSetName: rs1
sharding:
   clusterRole: shardsvr
security:
   clusterAuthMode: x509
net:
   tls:
      mode: requireTLS
      certificateKeyFile: <FILE_WITH_COMBINED_CERT_AND_KEY>
      CAFile: <CA_FILE>
   bindIp: localhost,<hostname(s)>

指定した構成で mongod を配置します。

mongod --config <PATH_TO_CONFIG_FILE>

注意

mongod インスタンスに --shardsvr オプションを指定すると、インスタンスはデフォルトでポート 27018 で実行されます。

レプリカセットの各ノードを起動します。
レプリカセットノードに接続します。
mongosh を使用して、レプリカセットノードの 1 つに接続します。以下に例を挙げます。
mongosh "mongodb://mongodb3.example.net:27018"
mongosh "mongodb://mongodb3.example.net:27018" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

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

mongosh で、rs.initiate() メソッドを実行して、現在のノードを含むレプリカセットを開始します。

rs.initiate( {
   _id : "rs1",
   members: [
       { _id: 0, host: "mongodb3.example.net:27018" },
       { _id: 1, host: "mongodb4.example.net:27018" },
       { _id: 2, host: "mongodb5.example.net:27018" }
   ]
} )

上記のコマンドでは、認証なしで管理アクションを実行するために localhost 例外が必要です。

重要

必ず 1 件のmongodインスタンス上でのみrs.initiate()を実行します。

レプリカセットの管理ユーザーを追加します。
レプリカセットを配置した後、localhost 例外を使用してレプリカセットの最初のユーザーを作成します。
1. レプリカセットのプライマリを決定します。
  プライマリを決定するには、rs.status() を実行します。
  rs.status()
  コマンド出力の replSetGetStatus.members[n].stateStr フィールドは、どのノードがプライマリであるかを示します。
2. レプリカセットプライマリに接続します。
  mongosh を使用してレプリカセットプライマリに接続します。たとえば、プライマリが mongodb4.example.net の場合は、次のコマンドを実行します。
  mongosh "mongodb://mongodb4.example.net:27018"
3. 管理ユーザーを作成します。
  次の db.createUser() メソッドを実行して、userAdmin ロールを持つ rs1Admin という名前のユーザーを作成します。
  use admin db.createUser( { user: "rs1Admin", pwd: passwordPrompt(), roles: [ { role: "userAdmin", db: "admin" } ] } )
  コマンドを実行すると、データベースによって rs1Admin ユーザーのパスワードを入力するように求められます。

2 つ目のレプリカセットをシャードとしてクラスターに追加する

新しいレプリカセット rs1 をシャーディングされたクラスターに追加します。

mongosh を mongos に接続します。
ホスト mongodb6.example.net で実行されている mongos インスタンスに接続するには、コマンドラインから次のコマンドを実行します。
mongosh "mongodb://admin01@mongodb6.example.net:27017/admin"
mongosh "mongodb://admin01@mongodb6.example.net:27017/admin" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
このコマンドは、シャーディングされたクラスターで作成した admin01 ユーザーとして認証します。コマンドを入力した後、ユーザーのパスワードを入力します。
2 つ目のシャードを追加します。
mongos に接続した後、sh.addShard() メソッドを使用して、レプリカセット rs1 をシャードとしてクラスターに追加します。
```
sh.addShard( "rs1/mongodb3.example.net:27018,mongodb4.example.net:27018,mongodb5.example.net:27018" )
```

コレクションのシャーディング

手順の最後のステップは、シャーディングされたクラスター内のコレクションをシャードすることです。

シャードキーを決定します。
コレクションのシャードキーを決定します。シャードキーは、MongoDB がシャード間でドキュメントを分散する方法を示します。よいシャードキー：
- すべてのドキュメント間で均等に分散された値を持ちます。
- 同時にアクセスされることが多いドキュメントを連続したチャンクにグループ化します。
- シャード間でのアクティビティの効率的な分散を可能にします。
詳しくは、「シャードキーを選択する」を参照してください。
この手順では、number フィールドを test_collection コレクションのシャードキーとして使用します。
シャードキーにインデックスを作成します。
空でないコレクションをシャードする前に、シャードキーにインデックスを作成します。
```
use test
db.test_collection.createIndex( { "number" : 1 } )
```
コレクションをシャーディングします。
test データベースで、test_collection をシャードします。シャードキーとして number を指定します。
```
sh.shardCollection( "test.test_collection", { "number" : 1 } )
```
次回バランサーが実行されると、ドキュメントのチャンクがシャード間で再分配されます。クライアントがこのコレクションに追加のドキュメントを挿入すると、mongos はドキュメントを適切なシャードにルーティングします。
バランサーがチャンクを再分配すると、アプリケーションのパフォーマンスに悪影響を与える可能性があります。パフォーマンスへの影響を最小限に抑えるために、バランサーがピーク時間帯に実行されないように、バランサーの実行時間を指定できます。詳しくは、「バランシング期間をスケジュールする」を参照してください。

詳細

シャーディングのチュートリアルと手順について詳しくは、次のページを参照してください。

戻る

シャーディングされたクラスターのレプリカセットへの変換

ストレージ

Overview

Considerations

重要

前提条件

手順

レプリカセットから既存のユーザーとロールを取得する

コンフィギュレーションサーバーのレプリカセットを配置する

重要

既存のユーザーとロールを新しい設定に復元する

コンフィギュレーションサーバーのレプリカセットを確保する

警告

次のコードを配置する: mongos

初期レプリカセットをシャードとして再起動する

注意

警告

--shardsvrオプションを使用してプライマリを再起動します。

警告

初期レプリカセットをシャードとして追加する

警告

アプリケーション接続文字列を更新する

2 つ目のレプリカセットを配置する

注意

重要

2 つ目のレプリカセットをシャードとしてクラスターに追加する

コレクションのシャーディング

詳細

次のコードを配置する: `mongos`

`--shardsvr`オプションを使用してプライマリを再起動します。