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つの方法は、各レプリケーションメンバーのサブドメインを構成するです。サブドメインの構成は実稼働環境または別の長期的なソリューションに理想的ですが、このチュートリアルでは、各サーバーのそれぞれのhostsファイルを編集してDNS解決を構成する方法の概要を説明します。

hostsは、人間が読める形式のホスト名を数値のIPアドレスに割り当てることができる特別なファイルです。つまり、いずれかのサーバーのIPアドレスが変更された場合でも、レプリカセットを再構成する代わりに、3台のサーバーのhostsファイルを更新するだけで済みます。

Linuxおよびその他のUnixライクなシステムでは、hostsは/etc/ディレクトリに保存されます。 3台のサーバーのそれぞれで、お好みのテキストエディタを使用してファイルを編集します。ここでは、nanoを使用します。

sudo nano /etc/hosts

localhost を構成する最初の数行の後に、レプリカセットの各メンバーのエントリを追加します。これらのエントリは、次の例のように、IPアドレスとそれに続く人間が読める形式の名前の形式を取ります。

/ etc / hosts

IP_address   any_hostname

必要なホスト名を使用するようにサーバーを構成できますが、各ホスト名をわかりやすくすることが役立つ場合があります。このガイド全体の例では、3つのサーバーが次のホスト名を使用します。

mongo0.replset.member
mongo1.replset.member
mongo2.replset.member

これらのホスト名を使用すると、/etc/hostsファイルは次の強調表示された行のようになります。

/ 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サイトです。 curlコマンドの引数としてURLを指定することにより、コマンドは、実行元のサーバーのIPアドレスを標準出力に出力します。

curl -4 icanhazip.com

DigitalOcean Dropletsを使用している場合は、コントロールパネルでもサーバーのIPアドレスを確認できます。

ここで追加する新しい行は、セット内の3つのホストのそれぞれで同一である必要があります。各サーバーでファイルを保存して閉じます。 nanoを使用してこれらのファイルを編集した場合は、CTRL + X、Y、ENTERの順に押して編集します。

各サーバーでhostsファイルを編集、保存、および閉じると、レプリカセットのDNS解決の構成が完了します。これで、各サーバーのファイアウォールルールを更新して、サーバーが相互に通信できるようにすることができます。

ステップ2—各サーバーのファイアウォール構成をUFWで更新する

前提条件の初期サーバーセットアップガイドに従っていると仮定すると、MongoDBをインストールし、OpenSSHUFWプロファイルへのアクセスを有効にした各サーバーにファイアウォールをセットアップします。これらのファイアウォールは現在、サーバー上の任意のポートへの接続をブロックしているため、これは重要なセキュリティ対策です。ただし、各サーバーのそれぞれのauthorized_keysファイルのキーと一致するキーを提示するssh接続は除きます。

ただし、これらのファイアウォールは、各サーバー上のMongoDBインスタンスが相互に通信することもブロックするため、レプリカセットを開始できなくなります。これを修正するには、新しいファイアウォールルールを追加して、MongoDBが接続をリッスンしている他の2つのサーバーのポートに各サーバーがアクセスできるようにする必要があります。

mongo0 で、次のufwコマンドを実行して、mongo1がmongo0のポート27017にアクセスできるようにします。

sudo ufw allow from mongo1_server_ip to any port 27017

mongo1サーバーの実際のIPアドレスを反映するようにmogno1_server_ipを変更してください。 ufwコマンドは、hostsファイルで構成されたホスト名では機能しないことに注意してください。このコマンド以降では、サーバーの実際のIPアドレスを使用してください。また、このサーバーのMongoインスタンスを更新してデフォルト以外のポートを使用する場合は、MongoDBインスタンスが実際に使用しているポートを反映するように27017を変更してください。

次に、別のファイアウォールルールを追加して、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がインストールされているサーバーで発生した接続のみを受け入れることができることを意味します。

リモート接続を許可するには、127.0.0.1に加えて、MongoDBをサーバーのパブリックにルーティング可能なIPアドレスにバインドする必要があります。このようにして、MongoDBインストールは、リモートマシンからMongoDBサーバーに対して行われた接続をリッスンできるようになります。

network interfacesセクションを見つけます。デフォルトでは次のようになります。

/etc/mongod.conf

. . .
# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1
. . .

bindIp:で始まりmongo0のホスト名またはパブリックIPアドレスが続く行にコンマを追加します。この例では、ステップ1で構成されたホスト名を使用します。

/etc/mongod.conf

. . .
# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1,mongo0.replset.member
. . .

次に、ファイルの下部に向かって#replication:と表示されている行を見つけます。次のようになります。

/etc/mongod.conf

. . .
#replication:
. . .

ポンド記号（#）を削除して、この行のコメントを解除します。次に、この行の下にreplSetNameディレクティブを追加し、その後にMongoDBがレプリカセットを識別するために使用する名前を追加します。

/etc/mongod.conf

. . .
replication:
  replSetName: "rs0"
. . .

この例では、replSetNameディレクティブの値は"rs0"です。ここでは任意の名前を指定できますが、わかりやすい名前を使用すると便利な場合があります。ただし、各サーバーのmongod.confファイルは、各MongoDBインスタンスが同じレプリカセットのメンバーになるために、replSetNameディレクティブの後に同じ名前を付ける必要があることに注意してください。

replSetNameディレクティブの前に2つのスペースがあり、名前が引用符（"）で囲まれていることに注意してください。どちらも、この構成を正しく読み取るために必要です。

ファイルのこれら2つのセクション、netとreplicationを更新すると、次のようになります。

/etc/mongod.conf

. . .
# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1,mongo0.replset.member
. . .
replication:
  replSetName: "rs0"
. . .

ファイルを保存して閉じます。次に、mongo1およびmongo2の/etc/mongod.confファイルに同じ変更を加えます。そうすると、これらの更新されたセクションは、mongo1の構成ファイルで次のようになります。

/etc/mongod.conf

. . .
# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1,mongo1.replset.member
. . .
replication:
  replSetName: "rs0"
. . .

そして、これらのセクションがmongo2の構成ファイルでどのように表示されるかを次に示します。

/etc/mongod.conf

. . .
# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1,mongo2.replset.member
. . .
replication:
  replSetName: "rs0"
. . .

繰り返しになりますが、各サーバーのbindIpディレクティブに追加するIPアドレスまたはホスト名は、編集しているmongod.confファイルを持つサーバーのIPアドレスまたはホスト名である必要があります。

各サーバーの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

プロンプトから、rs.initiate()メソッドを実行することにより、mongoシェルからレプリカセットを開始できます。ただし、このメソッドを単独で実行すると、メソッドを実行するマシンのレプリケーションのみが開始されるため、メンバーごとにrs.add()メソッドを発行して、他のMongoインスタンスを追加する必要があります。

MongoDBは、ドキュメントと呼ばれるJSONのような構造でデータを保存することを思い出してください。各サーバーでmongod.confファイルを編集して3つのMongoインスタンスをレプリケーション用に構成しているため、代わりにrs.initiateメソッド内に各メンバーの構成の詳細を保持するドキュメントを含めることができます。これにより、複数の個別のメソッドを実行する必要がなく、レプリカセットを開始し、各メンバーを一度に追加できます。

これを行うには、次のように入力してENTERを押して、rs.initiate()メソッドを開始します。

rs.initiate(

Mongoは、閉じ括弧を入力するまで、rs.initiateメソッドを完了として登録しません。そうするまで、プロンプトは大なり記号（>）から省略記号（...）に変わります。

JSONのオブジェクトと同様に、MongoDBのドキュメントは中括弧（{および}）で開始および終了します。レプリカセットの構成ドキュメントの追加を開始するには、最初の中括弧を入力します。

MongoDBドキュメントは、field: valueの形式をとる任意の数のフィールドと値のペアで構成されます。この特定のドキュメントの最初のフィールドと値のペアは、レプリカセットを識別するための名前を提供する_id:フィールドである必要があります。このフィールドの値は、mongod.confファイルで設定したreplSetNameディレクティブ（この例では"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()またはこれらのメソッドの別のいずれかを実行した後、クライアントプロンプトが再び次のように変わることがあります。

これは、接続しているMongoDBインスタンスがプライマリセットメンバーとして機能するように選択されたことを意味します。

将来レプリカセットに追加する追加のノードがある場合は、前のレプリカセットのメンバーと同じように構成した後、rs.add()メソッドを使用して追加できることに注意してください。手順：

rs.add( "mongo3.replset.member" )

これで、CTRL + Cを押すか、exitコマンドを実行して、MongoDBクライアントを閉じることができます。

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チュートリアルの全コレクションを確認することをお勧めします。