Ubuntu20.04でMongoDBレプリカセットを構成する方法
このチュートリアルの以前のバージョンは、 JustinEllingwoodによって作成されました。
序章
MongoDB は、多くの最新のWebアプリケーションで使用されているドキュメント指向のデータベースです。 従来のテーブルベースのリレーショナルデータベース構造に依存しないため、NoSQLデータベースとして分類されます。 代わりに、動的スキーマを持つJSONのようなドキュメントを使用します。 つまり、リレーショナルデータベースとは異なり、MongoDBでは、データベースにデータを追加する前に事前定義されたスキーマは必要ありません。
データベースを操作するときは、データの複数のコピーがあると便利なことがよくあります。 これにより、データベースサーバーの1つに障害が発生した場合に冗長性が提供され、データベースの可用性とスケーラビリティが向上し、読み取りの待ち時間が短縮されます。 複数の個別のデータベース間でデータを同期する方法は、レプリケーションと呼ばれます。 MongoDBでは、レプリケーションを通じて同じデータセットを維持するサーバーのグループは、レプリカセットと呼ばれます。
このチュートリアルでは、MongoDBでレプリケーションがどのように機能するかについて簡単に説明し、3つのメンバーでレプリカセットを構成して開始する方法の概要を説明します。 この構成例では、レプリカセットの各メンバーは、個別のUbuntu20.04サーバーで実行される個別のMongoDBインスタンスになります。
注:このガイドで概説されている手順は、レプリカをすばやくセットアップして実行する方法を示すことを目的としていることに注意してください。 このチュートリアルを完了すると、機能するレプリカセットが作成されますが、セキュリティ機能は有効になりません。 この設定は本番環境には推奨されません。
コミュニティバージョンのMongoDBには、データベースを安全に保つのに役立つ2つの認証方法、キーファイル認証とx.509認証が付属しています。 レプリケーションを使用する本番環境のデプロイメントでは、 MongoDBドキュメントはx.509認証の使用を推奨し、キーファイルを「テストまたは開発環境に最適な」「最低限のセキュリティ形式」として説明しています。 ただし、x.509証明書を取得して構成するプロセスには、ケースバイケースで行う必要のあるいくつかの警告と決定が伴います。これは、DigitalOceanチュートリアルの範囲を超えています。
レプリカセットをテストまたは開発に使用する場合は、 Ubuntu20.04でMongoDBレプリカセットのキーファイル認証を構成する方法に関するチュートリアルに従うことを強くお勧めします。
前提条件
このガイドを完了するには、次のものが必要です。
- それぞれがUbuntu20.04を実行している3台のサーバー。 これら3つのサーバーすべてに、ルート以外の管理ユーザーとUFWで構成されたファイアウォールが必要です。 これを設定するには、Ubuntu20.04の初期サーバー設定ガイドに従ってください。
- 各UbuntuサーバーにインストールされたMongoDB。 このためには、 Ubuntu 20.04 にMongoDBをインストールする方法に関するチュートリアルに従い、3つのサーバーすべてで各手順を完了してください。
わかりやすくするために、このガイドでは3つのサーバーを mongo0 、 mongo1 、およびmongo2と呼んでいることに注意してください。 mongo0 で実行されたコマンドまたはファイルの変更を示す例は、次のように青い背景になります。
-
mongo1 で実行されるコマンドとファイルの変更は、ピンク色の背景になります。
-
mongo2 のアクション例では、背景が緑色になります。
-
最後に、すべてのサーバーで実行する必要のあるコマンドまたはファイルの変更は、次のような標準の黒い背景になります。
-
MongoDBレプリカセットを理解する
はじめに述べたように、MongoDBはレプリカセットと呼ばれる実装を通じてレプリケーションを処理します。 特定のレプリカセットの一部であるMongoDBの実行中の各インスタンスは、そのメンバーの1つと呼ばれます。 すべてのレプリカセットには、1つのprimaryメンバーと少なくとも1つのsecondaryメンバーが必要です。
プライマリメンバーは、レプリカセットとのトランザクションのメインアクセスポイントであり、書き込み操作を受け入れることができる唯一のメンバーです。 レプリケーションはプライマリのoplog(「操作ログ」の略)をコピーし、セカンダリのそれぞれのデータセットでログに記録された変更を繰り返すことによって行われるため、各レプリカセットは一度に1つのプライマリメンバーのみを持つことができます。 書き込み操作を受け入れる複数のプライマリは、データの競合につながります。
デフォルトでは、アプリケーションは読み取り操作と書き込み操作の両方についてプライマリメンバーにのみクエリを実行します。 1つ以上の2次メンバーから読み取るようにセットアップを構成できますが、データは非同期で転送されるため、2次ノードからの読み取りにより古いデータが提供される可能性があります。 したがって、このような構成はすべてのユースケースに理想的ではありません。
MongoDBのレプリカセットを他のレプリケーション実装と区別する1つの機能は、自動フェイルオーバーメカニズムです。 プライマリメンバーが使用できなくなった場合、セカンダリノード間で自動選択プロセスが実行され、新しいプライマリが選択されます。 レプリカセットには最大50人のメンバーを含めることができますが、選挙では最大7人が投票できます。
ただし、セカンダリメンバープールに偶数のノードが含まれていると、投票の行き詰まりのために新しいプライマリを選択できなくなる可能性があります。 これには、レプリカセットに3番目のタイプのメンバーであるアービターを含める必要があります。 アービターは、レプリカセットのオプションのメンバーであり、このような状況で投票して、セットが決定に到達できるようにします。 ただし、アービターはデータセットのコピーを持っておらず、レプリカセットのプライマリになることを禁じられていることに注意してください。 レプリカセットにセカンダリメンバーが1つしかない場合は、アービターが必要です。
すべてのセカンダリがレプリカセットのセカンダリメンバーの標準ルールに従わないようにする場合があります。 MongoDBを使用すると、レプリカセットのセカンダリメンバーを構成して、次の非標準の役割を引き受けることができます。
- 優先度0のレプリケーションメンバー:特定のセットメンバーをプライマリポジションに選出すると、アプリケーションのパフォーマンスに悪影響を与える可能性がある状況がいくつかあります。 たとえば、データをリモートデータセンターに複製する場合、または特定のセカンダリメンバーのハードウェアがセットのメインアクセスポイントとして機能するには不十分である場合、その優先度を次のように設定します。
0
このメンバーがプライマリにならないようにすることができますが、データのコピーを続行できます。 - 非表示のレプリケーションメンバー:状況によっては、別の目的を持ち、読み取り操作に使用してはならないバックグラウンドメンバーを非表示にしながら、クライアントが1セットのメンバーにアクセスして表示できるようにする必要があります。 例として、分析作業のベースとなるセカンダリメンバーが必要になる場合があります。これは、最新のデータセットの恩恵を受けますが、作業メンバーに負担をかけることになります。 このメンバーを非表示に設定することにより、レプリカセットの一般的な操作に干渉することはありません。 非表示のメンバーは、の優先度に設定する必要があります
0
主要メンバーになることを避けるためですが、彼らは選挙に投票することができます。 - 遅延レプリケーションメンバー:セカンダリメンバーの遅延オプションを設定することにより、セカンダリがプライマリのoplogからコピーする各アクションの実行を待機する時間を制御できます。 これは、誤って削除されないように保護したり、破壊的な操作から回復したりする場合に便利です。 たとえば、セカンダリを半日遅らせた場合、セカンダリはそれ自体のデータセットに対して誤った操作をすぐに実行することはなく、変更を元に戻すために使用される可能性があります。 遅延メンバーはプライマリメンバーになることはできませんが、選挙に投票することはできます。 ほとんどの場合、アプリケーションプロセスが古いデータを読み取らないように、これらを非表示にする必要があります。
ステップ1—DNS解決の構成
手順4でレプリカセットを初期化するときは、セット内の他の2つのレプリカセットメンバーが到達できるアドレスを指定する必要があります。 MongoDBのドキュメントでは、レプリカセットを構成するときにIPアドレスを使用しないことを推奨しています。これは、IPアドレスが予期せず変更される可能性があるためです。 代わりに、MongoDB は、レプリカセットを構成するときに論理DNSホスト名を使用することをお勧めします。
これを行う1つの方法は、各レプリケーションメンバーのサブドメインを構成するです。 サブドメインの構成は実稼働環境または別の長期的なソリューションに理想的ですが、このチュートリアルでは、各サーバーのそれぞれを編集してDNS解決を構成する方法の概要を説明します。 hosts
ファイル。
hosts
は、人間が読める形式のホスト名を数値のIPアドレスに割り当てることができる特別なファイルです。 つまり、いずれかのサーバーのIPアドレスが変更された場合でも、更新する必要があるのは hosts
レプリカセットを再構成する代わりに、3台のサーバーでファイルを作成します。
Linuxおよびその他のUnixライクなシステムでは、 hosts
に保存されます /etc/
ディレクトリ。 3台のサーバーのそれぞれで、お好みのテキストエディタを使用してファイルを編集します。 ここでは、 nano
:
- sudo nano /etc/hosts
localhost を構成する最初の数行の後に、レプリカセットの各メンバーのエントリを追加します。 これらのエントリは、次の例のように、IPアドレスとそれに続く人間が読める形式の名前の形式を取ります。
IP_address any_hostname
必要なホスト名を使用するようにサーバーを構成できますが、各ホスト名をわかりやすくすることが役立つ場合があります。 このガイド全体の例では、3つのサーバーが次のホスト名を使用します。
- mongo0.replset.member
- mongo1.replset.member
- mongo2.replset.member
これらのホスト名を使用して、 /etc/hosts
ファイルは、次の強調表示された行のようになります。
. . .
127.0.0.1 localhost
203.0.113.0 mongo0.replset.member
203.0.113.1 mongo1.replset.member
203.0.113.2 mongo2.replset.member
. . .
サーバーのIPアドレスがわからない場合は、次のコマンドを実行できます curl
それらを取得するために各サーバーでコマンドを実行します。 icanhazip.com
は、アクセスに使用されているコンピュータのIPアドレスを表示するWebサイトです。 そのURLを引数として提供することによって curl
コマンドを実行すると、コマンドを実行したサーバーのIPアドレスが標準出力に出力されます。
- curl -4 icanhazip.com
DigitalOcean Dropletsを使用している場合は、コントロールパネルでもサーバーのIPアドレスを確認できます。
ここで追加する新しい行は、セット内の3つのホストのそれぞれで同一である必要があります。 各サーバーでファイルを保存して閉じます。 使用した場合 nano
これらのファイルを編集するには、を押して編集します CTRL + X
, Y
、 その後 ENTER
.
編集、保存、および閉じた後 hosts
各サーバー上のファイルがあれば、レプリカセットのDNS解決の構成が完了します。 これで、各サーバーのファイアウォールルールを更新して、サーバーが相互に通信できるようにすることができます。
ステップ2—各サーバーのファイアウォール構成をUFWで更新する
前提条件初期サーバーセットアップガイドに従っていると仮定すると、MongoDBをインストールし、 OpenSSH
UFWプロファイル。 これらのファイアウォールは現在、サーバー上の任意のポートへの接続をブロックしているため、これは重要なセキュリティ対策です。 ssh
各サーバーのそれぞれのキーと一致するキーを提示する接続 authorized_keys
ファイル。
ただし、これらのファイアウォールは、各サーバー上のMongoDBインスタンスが相互に通信することもブロックするため、レプリカセットを開始できなくなります。 これを修正するには、新しいファイアウォールルールを追加して、MongoDBが接続をリッスンしている他の2つのサーバーのポートに各サーバーがアクセスできるようにする必要があります。
mongo0 で、次を実行します ufw
mongo1ポートへのアクセスを許可するコマンド 27017
mongo0 :
- sudo ufw allow from mongo1_server_ip to any port 27017
必ず変更してください mogno1_server_ip
mongo1サーバーの実際のIPアドレスを反映します。 ご了承ください ufw
コマンドは、で構成されたホスト名では機能しません hosts
ファイルなので、このコマンドと次のコマンドでは、必ずサーバーの実際のIPアドレスを使用してください。 また、このサーバーのMongoインスタンスを更新してデフォルト以外のポートを使用する場合は、必ず変更してください 27017
MongoDBインスタンスが実際に使用しているポートを反映します。
次に、別のファイアウォールルールを追加して、mongo2に同じポートへのアクセスを許可します。
- sudo ufw allow from mongo2_server_ip to any port 27017
次に、他の2台のサーバーのファイアウォールルールを更新します。 mongo1 で次のコマンドを実行し、mongo0とmongo2のIPアドレスをそれぞれ反映するようにIPアドレスを変更してください。
- sudo ufw allow from mongo0_server_ip to any port 27017
- sudo ufw allow from mongo2_server_ip to any port 27017
最後に、mongo2でこれら2つのコマンドを実行します。 繰り返しになりますが、各サーバーに正しいIPアドレスを入力していることを確認してください。
- sudo ufw allow from mongo0_server_ip to any port 27017
- sudo ufw allow from mongo1_server_ip to any port 27017
これらのUFWルールを追加すると、3台のMongoDBサーバーのそれぞれが、他の2台のサーバーでMongoDBが使用するポートにアクセスできるようになります。 ただし、各サーバーのMongoインスタンスが現在外部接続をブロックしているため、これをまだテストすることはできません。 次の手順で各MongoDBインスタンスの構成ファイルを更新してレプリケーションを有効にすると、このテストを実行できるようになります。
ステップ3—各サーバーのMongoDB構成ファイルでレプリケーションを有効にする
この時点で、サーバーを編集しました。 /etc/hosts
それぞれのIPアドレスに解決されるホスト名を構成するファイル。 また、各サーバーのファイアウォールを開いて、他の2つのサーバーがデフォルトのMongoDBポートにアクセスできるようにしました。 27107
. これで、レプリケーションを有効にするために各サーバーでMongoDBインストールの構成を開始する準備が整いました。
このステップでは、MongoDBの構成ファイルを編集してこれを行う方法の概要を説明します。 /etc/mongod.conf
. このステップのすべての手順を各サーバーで完了する必要がありますが、デモンストレーションの目的で、例ではmongo0を使用します。
mongo0 で、お好みのテキストエディターでMongoDB構成ファイルを開きます。
- sudo nano /etc/mongod.conf
他のサーバーがポートにアクセスできるように各サーバーのファイアウォールを開いたとしても 27017
、MongoDBは現在にバインドされています 127.0.0.1
、ローカルループバックネットワークインターフェイス。 これは、MongoDBがインストールされているサーバーで発生した接続のみを受け入れることができることを意味します。
リモート接続を許可するには、MongoDBをサーバーのパブリックにルーティング可能なIPアドレスにバインドする必要があります。 127.0.0.1
. このようにして、MongoDBインストールは、リモートマシンからMongoDBサーバーに対して行われた接続をリッスンできるようになります。
を見つける network interfaces
セクション。 デフォルトでは次のようになります。
. . .
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1
. . .
で始まる行にコンマを追加します bindIp:
その後にmongo0のホスト名またはパブリックIPアドレスが続きます。 この例では、ステップ1で構成されたホスト名を使用します。
. . .
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo0.replset.member
. . .
次に、次の行を見つけます #replication:
ファイルの下部に向かって。 次のようになります。
. . .
#replication:
. . .
ポンド記号を削除して、この行のコメントを解除します(#
). 次に、 replSetName
この行の下にあるディレクティブの後に、MongoDBがレプリカセットを識別するために使用する名前が続きます。
. . .
replication:
replSetName: "rs0"
. . .
この例では、 replSetName
ディレクティブの値は "rs0"
. ここでは任意の名前を指定できますが、わかりやすい名前を使用すると便利な場合があります。 ただし、各サーバーの mongod.conf
ファイルは、 replSetName
各MongoDBインスタンスが同じレプリカセットのメンバーになるためのディレクティブ。
の前に2つのスペースがあることに注意してください replSetName
ディレクティブであり、名前が引用符で囲まれていること("
)、これらは両方とも、この構成を正しく読み取るために必要です。
ファイルのこれら2つのセクションを更新した後、 net
と replication
、次のようになります。
. . .
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo0.replset.member
. . .
replication:
replSetName: "rs0"
. . .
ファイルを保存して閉じます。 次に、これらの同じ変更を /etc/mongod.conf
mongo1およびmongo2上のファイル。 そうすると、これらの更新されたセクションは、mongo1の構成ファイルで次のようになります。
. . .
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo1.replset.member
. . .
replication:
replSetName: "rs0"
. . .
そして、これらのセクションがmongo2の構成ファイルでどのように表示されるかを次に示します。
. . .
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,mongo2.replset.member
. . .
replication:
replSetName: "rs0"
. . .
繰り返しになりますが、各サーバーに追加するIPアドレスまたはホスト名 bindIp
ディレクティブは、そのサーバーのディレクティブである必要があります mongod.conf
編集中のファイル。
各サーバーにこれらの変更を加えた後 mongod.conf
ファイルを作成し、各ファイルを保存して閉じます。 次に、再起動します mongod
次のコマンドを発行して、各サーバーでをサービスします。
- sudo systemctl restart mongod
これで、各サーバーのMongoDBインスタンスのレプリケーションが有効になりました。
注:この時点で、 nc
手順2で追加したファイアウォールルールが正しいかどうかをテストするコマンド。 nc
、 netcat の略で、TCPまたはUDPとのネットワーク接続を確立するために使用されるユーティリティです。 接続時にIPアドレスとポート番号の両方を指定できるため、このような場合のテストに役立ちます。
次の例 nc
コマンドには、 -z
オプション。これは、データを送信せずに、ターゲットサーバー上のリスニングデーモンのみをスキャンするようにユーティリティを制限します。 前提条件のインストールチュートリアルから、MongoDBがサービスデーモンとして実行されていることを思い出してください。このオプションは、接続のテストに役立ちます。 また、 v
コマンドの冗長性を高め、そうでない場合よりも多くの情報を返すようにするオプション。
この例 nc
コマンドは、mongo0からmongo1に到達する試みを示しています。
- nc -zv mongo1.replset.member 27017
次の出力は、mongo0がMongoDBで使用されるポートのmongo1に到達できることを示しています。
OutputConnection to mongo1.replset.member 27017 port [tcp/*] succeeded!
各サーバーでこのコマンドを繰り返し、適切なホスト名またはIPアドレスを指定することにより、サーバーの各ペア間の接続をテストできます。
各サーバーを編集した後 mongod.conf
レプリケーションを有効にして再起動するファイル mongod
サービスを使用すると、レプリカセットを開始し、各Mongoインスタンスをメンバーとして追加する準備が整います。
ステップ4—レプリカセットの開始とメンバーの追加
3つのMongoDBインストールのそれぞれを構成したので、MongoDBシェルを開いてレプリケーションを開始し、それぞれをメンバーとして追加できます。
デモンストレーションの目的で、このステップの例では、mongo0上のMongoDBインスタンスを使用してレプリカセットを開始します。 ただし、そのサーバーからレプリケーションを開始できます。 mongod.conf
ファイルが適切に構成されています。
mongo0 で、MongoDBシェルを開きます。
- mongo
プロンプトから、レプリカセットを開始できます。 mongo
を実行してシェル rs.initiate()
方法。 ただし、このメソッドを単独で実行すると、メソッドを実行するマシンのレプリケーションのみが開始されるため、を発行して他のMongoインスタンスを追加する必要があります。 rs.add()
各メンバーのメソッド。
MongoDBは、ドキュメントと呼ばれるJSONのような構造でデータを保存することを思い出してください。 すでに編集しているので mongod.conf
各サーバー上のファイルを使用して、レプリケーション用に3つのMongoインスタンスを構成します。代わりに、各メンバーの構成の詳細を保持するドキュメントを rs.initiate
方法。 これにより、複数の個別のメソッドを実行する必要がなく、レプリカセットを開始し、各メンバーを一度に追加できます。
これを行うには、 rs.initiate()
次のように入力してを押す方法 ENTER
:
- rs.initiate(
モンゴは登録しません rs.initiate
閉じ括弧を入力するまで、メソッドは完了します。 そうするまで、プロンプトは大なり記号(>
)省略記号(...
).
JSONのオブジェクトと同様に、MongoDBのドキュメントは中括弧で始まり、中括弧で終わります({
と }
). レプリカセットの構成ドキュメントの追加を開始するには、最初の中括弧を入力します。
- {
MongoDBドキュメントは、次の形式をとる任意の数のフィールドと値のペアで構成されます。 field: value
. この特定のドキュメントの最初のフィールドと値のペアは、 _id:
レプリカセットを識別するための名前を提供するフィールド。 このフィールドの値は、 replSetName
で設定したディレクティブ mongod.conf
ファイル、これは "rs0"
私たちの例では。
このフィールドと値のペアを入力し、その後にコンマを付けて、を押します。 ENTER
新しい行を開始するには:
- _id: "rs0",
次に、 members:
分野。 ただし、単一の値の代わりに、これに従ってください members:
複数のドキュメントを含む配列を持つフィールド。各ドキュメントは、追加するレプリカセットメンバーを表します。 MongoDBドキュメントでは、配列は常に角かっこ([
と ]
).
追加します members:
フィールドの後に角かっこを開いて配列を開始し、を押します ENTER
次の行に移動するには:
- members: [
次に、レプリカセットの最初のメンバーを表すために、コンマで区切られた2つのフィールドと値のペアを持つドキュメントを追加します。 このドキュメントの最初のフィールドは別のものです _id:
メンバーを内部的に識別するために使用される整数を受け入れるフィールド。 2番目は host:
フィールド。その後に、メンバーのMongoインスタンスに到達できるアドレスに解決されるホスト名を含む文字列を続ける必要があります。
- { _id: 0, host: "mongo0.replset.member" },
注:MongoインスタンスのいずれかがMongoDBのデフォルト以外のポートで実行されている場合— 27017
—ホスト名の後にコロンを付ける必要があります(:
)次に、次の例のようにポート番号を入力します。
- { _id: 0, host: "mongo0.replset.member:27018" },
最初のドキュメントを入力した後、レプリカセットの他のメンバーの追加のドキュメントを入力します。 各ドキュメントは必ずコンマで区切ります。
- { _id: 1, host: "mongo1.replset.member" },
- { _id: 2, host: "mongo2.replset.member" }
次に、閉じ角かっこを入力して配列を終了します。
- ]
最後に、構成ドキュメントを閉じ中括弧で終了し、閉じ括弧でメソッドを閉じます。
- })
一緒に、 rs.initiate()
メソッドは次のようになります。
> rs.initiate(
... {
... _id: "rs0",
... members: [
... { _id: 0, host: "mongo0.replset.member" },
... { _id: 1, host: "mongo1.replset.member" },
... { _id: 2, host: "mongo2.replset.member" }
... ]
... })
を押すと、すべての詳細を正しく入力したと仮定します ENTER
閉じ括弧を入力すると、メソッドが実行され、レプリカセットが開始されます。 メソッドが返す場合 "ok" : 1
出力では、レプリカセットが正しく開始されたことを意味します。
Output{
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1612389071, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1612389071, 1)
}
レプリカセットが期待どおりに開始された場合、MongoDBクライアントのプロンプトが大なり記号(>
)次のように:
-
MongoDBには、レプリカセットに関する情報を管理および取得するために使用できるいくつかの組み込みメソッドがインストールされています。 これらのうち、 rs.help()
メソッドは、これらのレプリカセットメソッドのリストとその機能の説明を返すため、特に役立ちます。
- rs.help()
Output rs.status() { replSetGetStatus : 1 } checks repl set status
rs.initiate() { replSetInitiate : null } initiates set with default settings
rs.initiate(cfg) { replSetInitiate : cfg } initiates set with configuration cfg
rs.conf() get the current configuration object from local.system.replset
rs.reconfig(cfg) updates the configuration of a running replica set with cfg (disconnects)
rs.add(hostportstr) add a new member to the set with default attributes (disconnects)
rs.add(membercfgobj) add a new member to the set with extra attributes (disconnects)
rs.addArb(hostportstr) add a new member which is arbiterOnly:true (disconnects)
rs.stepDown([stepdownSecs, catchUpSecs]) step down as primary (disconnects)
rs.syncFrom(hostportstr) make a secondary sync from the given member
rs.freeze(secs) make a node ineligible to become primary for the time specified
rs.remove(hostportstr) remove a host from the replica set (disconnects)
rs.secondaryOk() allow queries on secondary nodes
rs.printReplicationInfo() check oplog size and time range
rs.printSecondaryReplicationInfo() check replica set members and replication lag
db.isMaster() check who is primary
db.hello() check who is primary
reconfiguration helpers disconnect from the database so the shell will display
an error, even if the command succeeds.
走った後 rs.help()
またはこれらの方法の別の1つである場合、クライアントプロンプトが再び次のように変化することがあります。
-
これは、接続しているMongoDBインスタンスがプライマリセットメンバーとして機能するように選択されたことを意味します。
将来レプリカセットに追加したい追加のノードがある場合は、 rs.add()
前の手順で現在のレプリカセットメンバーを実行したのと同じように構成した後のメソッド:
- rs.add( "mongo3.replset.member" )
これで、を押してMongoDBクライアントを閉じることができます CTRL + C
またはを実行することによって exit
指図:
- exit
これでレプリカセットが稼働し、アプリケーションとの統合を開始できます。
警告:レプリカセットを開始するためにMongoDBプロンプトを開いたときに、次のような警告メッセージに気付いた可能性があります。
. . .
2021-02-03T21:45:48.379+00:00: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
. . .
このメッセージは、データベースのアクセス制御をまだ有効にしていないことを示しています。 MongoDBのドキュメントによると:
MongoDBは、役割ベースのアクセス制御(RBAC)を使用して、MongoDBシステムへのアクセスを管理します。 ユーザーには、データベースのリソースと操作へのユーザーのアクセスを決定する1つ以上の役割が付与されます。
どのMongoDBインスタンスでもアクセス制御が有効になっていないため、レプリカセット内の3つのサーバーのいずれかにアクセスできる人は誰でも、そのサーバー上のMongoインスタンスにアクセスできます。 これは、アプリケーションデータにもアクセスできる可能性があるため、重要なセキュリティリスクをもたらします。
この警告を削除し、レプリカセットにセキュリティのレイヤーを追加する1つの方法は、キーファイル認証を構成することです。 ただし、冒頭で述べたように、 MongoDBのドキュメントでは、キーファイルを「テストまたは開発環境に最適な」「最小限のセキュリティ形式」と説明しています。
実稼働環境では、 MongoDBのドキュメントでは、代わりに内部メンバー認証にx.509証明書を使用することを推奨していることに注意してください。 x.509証明書を取得して構成するプロセスには、ケースバイケースで行う必要のあるいくつかの警告と決定がありますが、これはこのチュートリアルの範囲を超えています。
レプリカセットをテストまたは開発に使用する場合は、 Ubuntu20.04でMongoDBレプリカセットのキーファイル認証を構成する方法に関するチュートリアルに従うことを強くお勧めします。
結論
データベースレプリケーションは、パフォーマンス、可用性、およびデータセキュリティを向上させるための戦略として広く使用されており、実稼働環境で使用されるデータベースで何らかの形式のレプリケーションを有効にすることが推奨されています。 レプリカも用途が広く、レポートや障害復旧など、データアーキテクチャでさまざまな役割を果たすことができます。 MongoDBのレプリカセットにある自動フェイルオーバー機能は、停止時にデータの高可用性を維持するのに役立つため、特に価値があります。
MongoDBについて詳しく知りたい場合は、MongoDBチュートリアルの全コレクションを確認することをお勧めします。