自己管理型シャーディングされたクラスターの配置
Overview
このチュートリアルでは、mongos
、コンフィギュレーションサーバーのレプリカセット、2 つのシャーディングされたレプリカセットで構成される新しいシャーディングされたクラスターを作成します。
Considerations
接続性
シャーディングされたクラスターの各ノードは、クラスター内の他のすべてのノードに接続できる必要があります。これには、すべてのシャードとコンフィギュレーションサーバーが含まれます。あらゆるインターフェースや、ファイアウォールなど、ネットワークとセキュリティ システムでこの接続が許可されていることを確認します。
ホスト名と構成
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
ローカルホストのデプロイ
ホスト識別子のホスト名部分に localhost
またはその IP アドレスを使用する場合、クラスター内の他の MongoDB コンポーネントのホスト設定としてその識別子を使用する必要があります。
たとえば、sh.addShard()
メソッドは、ターゲット シャードのホスト名として host
パラメータを受け取ります。host
を localhost
に設定する場合、クラスター内の他のすべてのシャードのホスト名にも、localhost
を使用する必要があります。
セキュリティ
このチュートリアルには、自己管理型配置で 自己管理型内部認証とメンバーシップ認証 や ロールベースのアクセス制御 を構成するために必要な手順は含まれて いませ ん 。
実稼働環境のシャーディングされたクラスターには、少なくとも x.509 セキュリティを内部認証とクライアントアクセスに採用する必要があります。
始める前に
MongoDB 8.0以降では、 directShardOperations
ロールを使用して、シャードに対してコマンドを直接実行する必要があるメンテナンス操作を実行できます。
警告
directShardOperations
ロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。 directShardOperations
ロールは、メンテナンス目的で、または MongoDB サポートのガイダンスに必ず従う必要があります。 メンテナンス操作を実行したら、 directShardOperations
ロールの使用を停止します。
手順
コンフィギュレーションサーバーのレプリカセットの作成
以下の手順でコンフィギュレーションサーバーのレプリカセットをデプロイします。
本番環境には、少なくとも 3 つのノードを含むコンフィギュレーションサーバーのレプリカセットをデプロイします。テスト用に、シングルノードのレプリカセットを作成できます。
注意
コンフィギュレーションサーバーのレプリカセットの名前には、どのシャードレプリカセットとも異なる名前を使用する必要があります。
このチュートリアルでは、コンフィギュレーションサーバーのレプリカセット ノードは次のホストに関連付けられています。
コンフィギュレーションサーバーのレプリカセット ノード | Hostname |
---|---|
Member 0 | cfg1.example.net |
Member 1 | cfg2.example.net |
Member 2 | cfg3.example.net |
コンフィギュレーションサーバーの各レプリカセット ノードを起動します。
各 mongod
を起動するときに、構成ファイルまたはコマンド ラインで mongod
設定を指定します。
構成ファイルを使用する場合、
sharding: clusterRole: configsvr replication: replSetName: <replica set name> net: bindIp: localhost,<hostname(s)|ip address(es)>
sharding.clusterRole
からconfigsvr
、replication.replSetName
希望するコンフィギュレーションサーバーのレプリカセットの名前に設定し、net.bindIp
オプションに、リモート クライアント (コンフィギュレーションサーバーのレプリカセットおよびシャーディングされたクラスターの他のノードを含む)がインスタンスに接続するために使用できるホスト名/IP アドレスまたはカンマ区切りのホスト名/IP アドレスのリストを設定します。警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
storage.dbPath
やnet.port
など、お使いの配置に適した追加設定。構成ファイルの詳細については、構成オプションを参照してください。
構成ファイル パスに --config
オプションを設定して、mongod
を起動します。
mongod --config <path-to-config-file>
コマンドライン オプションを使用する場合は、 --configsvr
、 --replSet
、 --bind_ip
、および配置に応じてその他のオプションを使用してmongod
を起動します。 例:
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
mongod --configsvr --replSet <replica set name> --dbpath <path> --bind_ip localhost,<hostname(s)|ip address(es)>
起動パラメータの詳細については、 mongod
リファレンス ページを参照してください。
複数のコンフィギュレーションサーバーうちいずれかに接続します。
mongosh
をコンフィギュレーションサーバーのノードの 1 つに接続します。
mongosh --host <hostname> --port <port>
レプリカセットを開始します。
mongosh
から、 rs.initiate()
メソッドを実行します。
rs.initiate()
は、オプションのレプリカセット構成ドキュメントを指定できます。レプリカセット構成ドキュメントには、次を含めます。
_id
は、replication.replSetName
または--replSet
オプションのいずれかで指定されたレプリカセット名に設定されます。コンフィギュレーションサーバーのレプリカセットの
configsvr
フィールドがtrue
に設定されます。レプリカセットの各ノードごとのドキュメントを含む
members
配列
重要
レプリカセットに対して 1 つの mongod
インスタンスでのみ rs.initiate()
を実行します。
rs.initiate( { _id: "myReplSet", configsvr: true, members: [ { _id : 0, host : "cfg1.example.net:27019" }, { _id : 1, host : "cfg2.example.net:27019" }, { _id : 2, host : "cfg3.example.net:27019" } ] } )
レプリカセットの構成ドキュメントについて詳しくは、「自己管理型レプリカセット構成」を参照してください。
コンフィギュレーションサーバーのレプリカセット(CSRS)を初期化し、起動したら、シャード レプリカセットの作成に進みます。
シャード レプリカセットの作成
本番環境には、少なくとも 3 つのノードを含むレプリカセットをデプロイします。テスト用に、シングルノードのレプリカセットを作成できます。
注意
シャード レプリカセットには、コンフィギュレーションサーバーのレプリカセットと同じ名前は使用できません。
各シャードに対してシャード レプリカセットを作成するには、次の手順を行います。
シャード レプリカセットの各ノードを起動します。
各 mongod
を起動するときに、構成ファイルまたはコマンド ラインで mongod
設定を指定します。
構成ファイルを使用する場合、
sharding: clusterRole: shardsvr replication: replSetName: <replSetName> net: bindIp: localhost,<ip address>
replication.replSetName
希望するレプリカセットの名前に設定し、sharding.clusterRole
オプションをshardsvr
へ、net.bindIp
オプションに、リモート クライアント(コンフィギュレーションサーバーのレプリカセットおよびシャーディングされたクラスターの他のノードを含む)がインスタンスに接続するために使用できる IP アドレスまたはカンマ区切りの IPアドレス リストを設定します。警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
storage.dbPath
やnet.port
など、お使いの配置に適した追加設定。構成ファイルの詳細については、構成オプションを参照してください。
構成ファイル パスに --config
オプションを設定して、mongod
を起動します。
mongod --config <path-to-config-file>
シャード レプリカセットのいずれか 1 つのノードに接続します。
mongosh
レプリカ セット ノードの 1 つに接続します。
mongosh --host <hostname> --port <port>
レプリカセットを開始します。
mongosh
から、 rs.initiate()
メソッドを実行します。
rs.initiate()
は、オプションのレプリカセット構成ドキュメントを指定できます。レプリカセット構成ドキュメントには、次を含めます。
_id
は、replication.replSetName
または--replSet
オプションのいずれかで指定されたレプリカセット名に設定されます。レプリカセットの各ノードごとのドキュメントを含む
members
配列
次の例では、ノードが 3 つあるレプリカセットを初期化します。
重要
レプリカセットに対して 1 つの mongod
インスタンスでのみ rs.initiate()
を実行します。
rs.initiate( { _id : "myReplSet", members: [ { _id : 0, host : "s1-mongo1.example.net:27018" }, { _id : 1, host : "s1-mongo2.example.net:27018" }, { _id : 2, host : "s1-mongo3.example.net:27018" } ] } )
シャーディングされたクラスターの を開始しますmongos
mongos
を起動するには、構成ファイルまたはコマンドライン パラメータを使用して構成サーバーを指定します。
構成ファイルを使用する場合は、sharding.configDB
をコンフィギュレーションサーバーのレプリカセット名に設定し、レプリカセットの少なくとも 1 つのノードを <replSetName>/<host:port>
形式で設定します。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
sharding: configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019 net: bindIp: localhost,<hostname(s)|ip address(es)>
--config
オプションと構成ファイルへのパスを指定して、mongos
を起動します。
mongos --config <path-to-config>
構成ファイルの詳細については、構成オプションを参照してください。
コマンドライン パラメーターを使用する場合は、mongos
を起動し、配置に応じて --configdb
、--bind_ip
などのオプションを指定します。たとえば次のとおりです。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
mongos --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,cfg3.example.net:27019 --bind_ip localhost,<hostname(s)|ip address(es)>
配置に適したその他のオプションを含めます。
この時点で、シャーディングされたクラスターは mongos
サーバーとコンフィギュレーションサーバーで構成されています。mongosh
を使用してシャーディングされたクラスターに接続できるようになりました。
シャーディングされたクラスターへの接続
mongosh
をmongos
に接続します。 mongos
が実行されているhost
とport
を指定します。
mongosh --host <hostname> --port <port>
クラスターへのシャードの追加
mongos
に接続されている mongosh
セッションで、sh.addShard()
メソッドを使用して各シャードをクラスターに追加します。
次の操作では、単一のシャード レプリカセットをクラスターに追加します。
sh.addShard( "<replSetName>/s1-mongo1.example.net:27018,s1-mongo2.example.net:27018,s1-mongo3.example.net:27018")
クラスターに必要なシャードがすべて含まれるまで、これらの手順を繰り返します。
コレクションのシャーディング
コレクションをシャードするには、mongosh
を mongos
に接続し、sh.shardCollection()
メソッドを使用します。
注意
シャーディングとインデックス
コレクションにすでにデータが含まれている場合は、コレクションをシャードする前に、シャード キーをサポートするインデックスを作成する必要があります。コレクションが空の場合、MongoDB により sh.shardCollection()
の一部としてインデックスが作成されます。
MongoDB でコレクションをシャードするには、次の 2 つの方法があります。
ハッシュ シャーディングでは、1 つのフィールドのハッシュ インデックスをシャードキーとして使用して、シャーディングされたクラスター間でデータをパーティショニングします。
sh.shardCollection("<database>.<collection>", { <shard key field> : "hashed" } ) 範囲ベースのシャーディングでは、複数のフィールドをシャードキーとして使用して、シャードキー値によって決定される連続した範囲にデータを分割できます。
sh.shardCollection("<database>.<collection>", { <shard key field> : 1, ... } )
シャードキーの考慮事項
シャードキーの選択は、シャーディングの効率だけでなく、 ゾーンなどの特定のシャーディング機能を利用する能力にも影響します。効果的なシャードキーを選択する方法については、「シャードキーの選択」を参照してください。
mongosh
は、convertShardKeyToHashed()
メソッドを提供します。このメソッドでは、ハッシュインデックスと同じハッシュ関数が使用され、キーのハッシュ値を確認できます。
Tip
以下も参照してください。
ハッシュ シャーディングのシャードキーについて詳しくは、「ハッシュ シャーディングのシャードキー」を参照してください。
範囲ベースのシャーディングのシャードキーについて詳しくは、「シャードキー選択」を参照してください。