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

シャードクラスターは、シャードキーに基づいて複数のサーバー間でデータを分割します。大規模なデータセットと高スループット操作を伴う配置では、シャーディングされたクラスターの方がレプリカセットよりも拡張性に優れています。

このチュートリアルでは、単一の 3 ノードのレプリカセットを 2 つのシャードを持つシャーディングされたクラスターに変換します。新しいクラスター内の各シャードは、独立した 3 つのノードのレプリカセットです。

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

このタスクについて

このチュートリアルは、認証が有効になっている配置を対象としています。
このチュートリアルでは、構成ファイルを使用してサーバー設定を指定します。構成ファイルには、mongod および mongos コマンドラインオプションと同等の設定が含まれています。
このチュートリアルで配置されるするシャーディングされたクラスターには、10 台のサーバーが含まれます。
- mongos. 用の 1 つのサーバー。
- クラスター内の 2 つのシャードごとに 3 台のサーバー（合計 6 台のサーバー）。
- コンフィギュレーションサーバーのレプリカセット用の 3 台のサーバー。
レプリカセットでクエリ分析を実行中、それを専用のコンフィギュレーションサーバーを使用してシャーディングされたクラスターに変換すると、クエリ分析が停止します。

サーバーアーキテクチャ

このチュートリアルでは次のサーバーを使用します。

Hostname	ポート	説明
`mongodb0.example.net`	`27017`	初期データ保持シャード `rs0` のノード。
`mongodb1.example.net`	`27017`	初期データ保持シャード `rs0` のノード。
`mongodb2.example.net`	`27017`	初期データ保持シャード `rs0` のノード。
`mongodb3.example.net`	`27018`	2 つ目のデータ保持シャード `rs1` のノード。
`mongodb4.example.net`	`27018`	2 つ目のデータ保持シャード `rs1` のノード。
`mongodb5.example.net`	`27018`	2 つ目のデータ保持シャード `rs1` のノード。
`mongodb6.example.net`	`27017`	シャーディングされたクラスターに接続するために使用される `mongos`。
`mongodb7.example.net`	`27019`	コンフィギュレーションサーバーのレプリカセットのノード。
`mongodb8.example.net`	`27019`	コンフィギュレーションサーバーのレプリカセットのノード。
`mongodb9.example.net`	`27019`	コンフィギュレーションサーバーのレプリカセットのノード。

このチュートリアルで使用されているホスト名は例です。サンプルコマンドで使用されているホスト名を、配置で使用されているホスト名に置き換えます。

重要

IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセットノードまたはシャーディングされたクラスターノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。

分裂されたネットワークホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。

始める前に

このチュートリアルを完了するには、キーファイルまたは X.509 証明書認証のいずれかを使用するレプリカセットが必要です。これらの認証方法のいずれかを使用する安全なレプリカセットを配置するには、次のいずれかを参照してください。
- キーファイル認証を使用した自己管理型レプリカセットの配置
- 自己管理型MongoDBで X.509 を使用してクラスターメンバーシップを検証
このチュートリアルでは、デフォルトのデータディレクトリ /data/db と /data/configdb を使用します。別のパスを使用するには、構成ファイルで storage.dbPath を設定します。
レプリカセットでクエリ分析を実行中、それを専用のコンフィギュレーションサーバーを使用してシャーディングされたクラスターに変換すると、クエリ分析が停止します。

手順

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

既存のユーザーとロールを取得するには、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,<ipaddress>

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

コンフィギュレーションサーバーを起動する
指定した構成で mongod を配置します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```
コンフィギュレーションサーバーは、デフォルトのデータディレクトリ /data/configdb とデフォルトのポート 27019 を使用します。
複数のコンフィギュレーションサーバーうちいずれかに接続します。
Use mongosh to connect to one of the config servers. For example:
```
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,<ipaddress>

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

次の各ホストで 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,<ipaddress>

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,<ipaddress>

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

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,<ipaddress>

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

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 設定を指定します。

初期レプリカセットのノードに接続します。
Use mongosh to connect to one of the members of your initial replica set.
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 オプションを使用してセカンダリを再起動します。

セカンダリに接続します。
Use mongosh to connect to one of the secondaries.
```
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,<ipaddress>
```
配置に応じて、オプションを追加します。
セカンダリをシャードサーバーとして再起動します。
セカンダリを含むホストで次のコマンドを実行します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```
他のセカンダリに対してもシャットダウンと再起動の手順を繰り返します。

セカンダリに接続します。
Use mongosh to connect to one of the secondaries.
If your deployment uses X.509 authentication, specify these mongosh options:
```
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,<ipaddress>

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

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

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

プライマリに接続します。
Use mongosh to connect to the primary:
```
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,<ipaddress>
```
配置に応じて、オプションを追加します。
プライマリをシャードサーバーとして再起動します。
プライマリを含むホストで次のコマンドを実行します。
```
mongod --config <PATH_TO_CONFIG_FILE>
```

プライマリに接続します。
Use mongosh to connect to one of the secondaries.
If your deployment uses X.509 authentication, specify these mongosh options:
If your deployment uses X.509 authentication, specify these mongosh options:
```
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,<ipaddress>

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"
If your deployment uses X.509 authentication, specify these mongosh options:
If your deployment uses X.509 authentication, specify these mongosh options:

--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,<ipaddress>

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

各ノードに対して、次のオプションで 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,<ipaddress>

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

mongod --config <PATH_TO_CONFIG_FILE>

注意

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

レプリカセットの各ノードを起動します。
レプリカセットノードに接続します。
Use mongosh to connect to one of the replica set members. For example:
mongosh "mongodb://mongodb3.example.net:27018"
mongosh "mongodb://mongodb3.example.net:27018" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>

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

In mongosh, run the rs.initiate() method to initiate a replica set that contains the current member:

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. レプリカセットプライマリに接続します。
  Connect to the replica set primary with mongosh. For example, if the primary is mongodb4.example.net, run this command:
  mongosh "mongodb://mongodb4.example.net:27018"
  mongosh "mongodb://mongodb4.example.net:27018" --tls --tlsCAFile <CA_FILE> --tlsCertificateKeyFile <filename>
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 はドキュメントを適切なシャードにルーティングします。
バランサーがチャンクを再分配すると、アプリケーションのパフォーマンスに悪影響を与える可能性があります。パフォーマンスへの影響を最小限に抑えるために、バランサーがピーク時間帯に実行されないように、バランサーの実行時間を指定できます。詳しくは、「バランシング期間をスケジュールする」を参照してください。

詳細

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

戻る

シャードクラスタのレプリカセットへの変換

参照

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

このタスクについて

サーバー アーキテクチャ

始める前に

手順

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

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

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

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

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

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

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

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

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

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

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

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

詳細

サーバーアーキテクチャ

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

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