自己管理型レプリカセットのシャーディングされたクラスターへの変換
シャード クラスターは、 シャード キーに基づいて複数のサーバー間でデータを分割します。大規模なデータセットと高スループット操作を伴う配置では、シャーディングされたクラスターの方がレプリカセットよりも拡張性に優れています。
このチュートリアルでは、単一の 3 ノードのレプリカセットを 2 つのシャードを持つシャーディングされたクラスターに変換します。新しいクラスター内の各シャードは、独立した 3 つのノードのレプリカセットです。
このタスクについて
このチュートリアルの一部の手順では、配置のダウンタイムが発生します。個々の手順で、ダウンタイムがいつ発生するかを示します。
このチュートリアルは、認証が有効になっている配置を対象としています。
このチュートリアルでは、構成ファイルを使用してサーバー設定を指定します。構成ファイルには、
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 証明書認証のいずれかを使用するレプリカセットが必要です。これらの認証方法のいずれかを使用する安全なレプリカセットを配置するには、次のいずれかを参照してください。
このチュートリアルでは、デフォルトのデータディレクトリ
/data/db
と/data/configdb
を使用します。別のパスを使用するには、構成ファイルでstorage.dbPath
を設定します。MongoDB は、シャードに対して コマンドを直接実行できるようにすることで、レプリカセットから1シャード クラスターへのオンライン移行をサポートしています。 ただし、クラスターに複数のシャードがある場合は、リストされているコマンドのみが、メンテナンス専用の
directShardOperations
ロールなしでシャードに対して直接実行できます。
手順
注意
MongoDB 8.0以降では、シャードで特定のコマンドのみを実行できます。 シャードに直接接続し、サポートされていないコマンドを実行しようとすると、MongoDB はエラーを返します。
"You are connecting to a sharded cluster improperly by connecting directly to a shard. Please connect to the cluster via a router (mongos)."
サポートされていないデータベースコマンドをシャードに対して直接実行するには、 mongos
に接続するか、メンテナンス専用のdirectShardOperations
ロールが必要です。
コンフィギュレーションサーバーのレプリカセットを配置する
コンフィギュレーションサーバーに 3 つのノードのレプリカセットを配置します。この例では、コンフィギュレーションサーバーは次のホストを使用します。
mongodb7.example.net
mongodb8.example.net
mongodb9.example.net
コンフィギュレーションサーバーを設定する
各コンフィギュレーションサーバー ホストで
mongod
インスタンスを構成します。各mongod
インスタンスの 構成ファイル で次のオプションを指定します。オプション値configReplSet
configsvr
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: <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
インスタンスの構成ファイルで次のオプションを指定します。オプション値x509
requireTLS
TLS 証明書とキーの両方を含む.pem
ファイルへの絶対パス。認証局からのルート証明書チェーンを含む.pem
ファイルへの絶対パス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
構成ファイルで次のオプションを指定します。オプション値configReplSet
、その後にスラッシュ/
と、コンフィギュレーションサーバーのホスト名とポートの少なくとも 1 つが続きます。最初のレプリカセット用のキー ファイルへのパス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
構成ファイルで次のオプションを指定します。オプション値configReplSet
、その後にスラッシュ/
と、コンフィギュレーションサーバーのホスト名とポートの少なくとも 1 つが続きます。x509
requireTLS
TLS 証明書とキーの両方を含む.pem
ファイルへの絶対パス。認証局からのルート証明書チェーンを含む.pem
ファイルへの絶対パス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
設定を設定します。
初期レプリカセットのノードに接続します。
mongosh
を使用して、初期レプリカセットのノードの 1 つに接続します。mongosh "mongodb://<username>@mongodb0.example.net:27017" 配置で x.509 認証を使用する場合は、次の
mongosh
オプションを指定します。以下に例を挙げます。
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
上で実行されています。このコマンドは、シャーディングされたクラスターで作成した
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
を開始します。オプション値rs1
shardsvr
x509
requireTLS
TLS 証明書とキーの両方を含む.pem
ファイルへの絶対パス。認証局からのルート証明書チェーンを含む.pem
ファイルへの絶対パス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 例外 を使用してレプリカセットの最初のユーザーを作成します。
レプリカセットのプライマリを決定します。
プライマリを決定するには、
rs.status()
を実行します。rs.status() コマンド出力の
replSetGetStatus.members[n].stateStr
フィールドは、どのノードがプライマリであるかを示します。レプリカセット プライマリに接続します。
mongosh
を使用してレプリカセット プライマリに接続します。たとえば、プライマリがmongodb4.example.net
の場合は、次のコマンドを実行します。mongosh "mongodb://mongodb4.example.net:27018" 管理ユーザーを作成します。
次の
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
はドキュメントを適切なシャードにルーティングします。バランサーがチャンクを再分配すると、アプリケーションのパフォーマンスに悪影響を与える可能性があります。パフォーマンスへの影響を最小限に抑えるために、バランサーがピーク時間帯に実行されないように、バランサーの実行時間を指定できます。詳しくは、「バランシング期間をスケジュールする」を参照してください。
詳細
シャーディングのチュートリアルと手順について詳しくは、次のページを参照してください。