Ubuntu20.04でMongoDBレプリカセットを構成する方法

このチュートリアルの以前のバージョンは、 JustinEllingwoodによって作成されました。

序章

MongoDB は、多くの最新のWebアプリケーションで使用されているドキュメント指向のデータベースです。 従来のテーブルベースのリレーショナルデータベース構造に依存しないため、NoSQLデータベースとして分類されます。 代わりに、動的スキーマを持つJSONのようなドキュメントを使用します。 つまり、リレーショナルデータベースとは異なり、MongoDBでは、データベースにデータを追加する前に事前定義されたスキーマは必要ありません。

データベースを操作するときは、データの複数のコピーがあると便利なことがよくあります。 これにより、データベースサーバーの1つに障害が発生した場合に冗長性が提供され、データベースの可用性とスケーラビリティが向上し、読み取りの待ち時間が短縮されます。 複数の個別のデータベース間でデータを同期する方法は、レプリケーションと呼ばれます。 MongoDBでは、レプリケーションを通じて同じデータセットを維持するサーバーのグループは、レプリカセットと呼ばれます。

このチュートリアルでは、MongoDBでレプリケーションがどのように機能するかについて簡単に説明し、3つのメンバーでレプリカセットを構成して開始する方法の概要を説明します。 この構成例では、レプリカセットの各メンバーは、個別の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
. . .

curl -4 icanhazip.com

ここで追加する新しい行は、セット内の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 -zv mongo1.replset.member 27017

Output
Connection to mongo1.replset.member 27017 port [tcp/*] succeeded!

各サーバーを編集した後 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" },

{ _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

これでレプリカセットが稼働し、アプリケーションとの統合を開始できます。

. . .
        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について詳しく知りたい場合は、MongoDBチュートリアルの全コレクションを確認することをお勧めします。