MongoDBのレプリケーションと自動フェイルオーバーの設定方法

レプリカセット（replica set） は、ノード間でレプリケーションと自動フェイルオーバーが構成された、複数ノードによるデータベースクラスターとして定義されます。PRIMARY データベースが正しく選出されるようにするために、セット内のメンバー数（Arbiter ノードを含む、または除く）を奇数にすることが重要です。 

選出されたデータベースは、すべての主要なタスクを担当します。書き込み操作を処理し、その情報を oplog に保存します。この情報は、SECONDARY レプリカメンバーによってアクセスおよび複製され、独自のデータセットに適用されます。その結果、セット内のすべてのサーバーが同じコンテンツを保持し、その可用性が確保されます：

ここで、予期しない問題（ハードウェアや接続の障害など）によってプライマリデータベースがダウンタイムを発生させる状況を考えてみましょう。このような場合、システムは手動での介入を必要とせずに、通常の機能を復元するための新しい選出プロセスを自動的に開始します。このようなシステムの利点は、以下の優れた機能を最大限に活用できることです：レプリケーション（可用性の向上、フェイルオーバーの冗長性、災害復旧など）。複数のデータベースを個別に管理することを心配する必要はありません。

同様のシステムを採用したい場合、このチュートリアルでは、CloudSigma PaaS を使用して MongoDB レプリカセットを構成する方法を説明します。このガイドで説明するように、3つのメンバーを使用します。これは通常、ほとんどの一般的なアプリケーションの I/O 操作を処理するための十分な情報安全性と処理能力を確保するのに十分です。レプリケーションの実際の構成に加えて、環境の準備、DB ノード間の認証の設定、および作業が成功したことを確認する方法についても説明します。

ステップ 1：新しい環境の作成

まず、レプリカセットの構成を開始するには、少なくとも 3 つの MongoDB ノードが必要です。それでは、次のように新しい環境を作成しましょう：

この例では、バージョン 4.0.2 のすべての MongoDB インスタンスを同じ環境に割り当てています。必要に応じて、指定されたスペースで環境名（Environment Name） を変更し、インストールプロセスを続行できます。

プロセスの次のステップでは、認証キーファイルを使用して、これらのノード間の通信のセキュリティを処理します。

ステップ 2：認証キーファイルの追加

認証は、あらゆるレプリケーションの重要なコンポーネントです。これは、一意の認証キーファイルを使用して正しく識別された後にのみ、レプリカセットメンバーへのアクセスを許可するセキュリティ保証プロセスです。これにより、不要な傍観者や第三者からデータを安全に保護できます。独自の認証キーファイルを生成する方法は次のとおりです：

1. いずれかのデータベースノードのWeb SSH オプションをクリックしてログインします：

    2. 次に、独自のキーファイルを入力するか、次のコマンドを使用して openssl で新しいキーファイルを生成します：

このコマンドにおいて、741 はバイト単位のキーサイズを表し、 my.key はキーの名前です。

    3. 新しいキーファイルをすべての MongoDB インスタンスに配布します。手順は次のとおりです：

• いずれかのデータベースノードの横にある File Manager を、Config ボタンをクリックして開きます：

• 次のパスの下にある設定タブで、 my.key ファイルを見つけます： /home/jelastic/my.key. これを開き、ファイルの内容をコピーします：

• パス /var/lib/jelastic/keys の下に、 keys ディレクトリがあります。MongoDB インスタンスがお互いのアイデンティティを認証するために使用する New File を作成します。この例では、次のような名前のファイルを作成します： mongo-set.key:

• 以前にコピーした内容をこのファイルに貼り付け、すべてのインスタンスで Save をクリックして変更を適用します：

このプロセスの結果、 mongo-set.key ファイルがすべての MongoDB ノードに配布されました。

ステップ 3：MongoDB レプリケーションの構成

インスタンスのセキュリティが確保されたので、実際にレプリカセットの構成に進むことができます。始めましょう：

1. まず、MongoDB ノードの設定タブに移動し、次のファイルを開きます： mongo.conf ファイルを、次のディレクトリから開きます：etc フォルダ。レプリケーション（replication）セクションが見つかるまで下にスクロールします。コメントアウトを解除し、レプリカセットの一意の名前を含む次の文字列を追加します。この例では、名前を db-replication:

      2. 次に、という新しいパラメータを追加します keyFile（securityセクション内）。これは、現在次のパスにあるキーファイルへのパスを指定するために機能します： /var/lib/jelastic/keys/mongo-set.key:

      3. 適切なボタンをクリックして、保存（Save）します（変更をすべてのインスタンスに対して、エディタウィンドウで）。 

      4. ここで、再起動する必要があります（すべてのDBノードを。新しい設定パラメータを適用するため）：

注意点として、レプリカセットの構成が完了し、すべてのノードまたはPRIMARYノードを再起動すると、再起動中に新しいPRIMARYデータベースの選出プロセスが開始されます。

     5. PRIMARYとして使用するMongoDBサーバーを選択し、SSHプロトコルを使用してアクセスします：

注意：PRIMARYデータベースが選出されると、他のレプリカセットメンバーは直接の書き込み操作のためにアクセスできなくなります。これは、すべての変更と構成が現在のPRIMARYノードに対してのみ実行および適用できることを意味します。そのため、あらかじめ優先度（priorities）を設定していない限り、アプリケーションの接続文字列を新しいPRIMARYノードに変更する必要があります。

     6. 次に、それぞれの資格情報を使用してレプリケートされたデータベースにアクセスします：

このコマンドにおいて：

• {user} –メールに送信される管理者ユーザー名を指します（通常、デフォルトはadminです）。

• {password} –これは、対応するユーザー名と一緒にメールに送信されたパスワードです。

• {DB_name}- このレプリカセットでレプリケートするデータベースの名前を表します（この例ではデフォルトのadminを使用しています）。

新しい選出が行われた場合、同じadminユーザーの資格情報を使用して新しいPRIMARYデータベースにログインできます。

     7. 接続が確立されたので、次の行を実行して現在のMongoDBノードのパラメータを定義し、レプリカセットを開始する必要があります：

上記の行では、括弧内の値を対応する独自のデータに置き換えます：

• {replica_set} – これは、このセクションの最初で指定したレプリケートするデータベースグループの名前です。この例では、db-replicationでした。

• {current_db_ip} – 選択したデータベースコンテナのIPアドレスを示します：

この例では、実行される行は次のとおりです：

        8. 次に、残りのすべてのデータベースに対して次のコマンドを実行します：

ここで、{db_ip} は各データベースのIPアドレスを指します：

       9. すべてのレプリケーションメンバーを追加すると、完全に機能するレプリカセットが得られます。プロセスの最後に、すべてが正しく構成されていることを確認することをお勧めします。確認するには、次のコマンドを実行します： rs.status()。これにより、次のようにレプリカセットに関する完全な情報が表示されます：

ステップ 4: レプリカセットの仲裁者（Arbiter）のセットアップ

特定のケースでは、仲裁者（Arbiter）ノードを使用することをお勧めします。そもそも仲裁者（Arbiter）ノードとは何でしょうか？通常、レプリカセットに含まれるノード数が奇数の場合、レプリケーションの信頼性が高まります。そのため、現在セット内のノード数が偶数の場合は、仲裁者（Arbiter）ノードを追加して、セット内の他のメンバーからのハートビートや選出要求に応答し、クォーラム（定足数）を維持することができます。以下は、仲裁者（Arbiter）ノードに関する詳細です：

• Arbiterはデータを一切保存しません。別のノードが障害を起こした場合に、選挙で投票するだけです。
• 非常に軽量で、リソースをほとんど消費しません。
• 暗号化されたレプリカ間でユーザー資格情報を交換しました。
• 最高の可用性を維持するために、Arbiterを別のノードで実行してみてください。

レプリカセットにArbiterノードを追加する方法は次のとおりです。

1. まず、水平スケーリングを行い、クラスターにノードを追加します。

2. ノードが追加されたら、新しいキーファイルが必要になります。次のディレクトリに移動します。 keys ディレクトリに移動し、キーファイルを作成します。 mongo-set.key。以前に設定したデータベースノードのいずれかからキーの内容をコピーし、前と同じようにここにすべて貼り付けます。

3. 次のファイルに移動します。 mongod.conf 設定ファイル。replicationセクションのコメントアウトを解除し、以下を追加します。 repISetName （今回の場合は db-replication です）。また、次のセクションに移動します。 security セクションに移動し、次のパラメータを追加します。 keyFile パラメータ（今回の場合は /var/lib/jelastic/keys/mongo-set.key です）。

4. 最後に、新しいノードを再起動して、これらの新しい設定パラメータを適用します。

現時点でクラスター内のすべてのノードを再起動する必要は「ない」ことに注意してください。新しく追加されたArbiterノードのみを再起動します。すべてのノードを再起動すると、新しいPRIMARYの選出が行われます（特定のデータベースノードをPRIMARYとして選択するように優先度を指定している場合を除く）。

 5. 最後に、Arbiterをレプリカセットに追加できます。これを行うには、PRIMARYノードで次のコマンドを実行します。

ここで、 {db_ip} は新しいノードのIPアドレスです：

 6. これで、新しいノードがArbiterになったかどうかを確認できます。これを行うには、SSHを使用して新しいノードにログインし、ノード作成時にメールで受信した資格情報を使用してMongoDBインスタンスに接続します。

これは、クラスターに追加したばかりの新しいノードが、次のArbiterとして機能していることを示しています。 db-replication。これにより、どのような状況でもクォーラムが確保され、レプリカセットの信頼性が向上します。

ステップ 5: データベースクラスターの可用性のテスト

次に、リモートで接続して操作を実行できるようにMongoDBクラスターを設定します。次の例では、シンプルなPHPアプレットを使用して接続し、いくつかの確認コマンドを実行します。

この目的のために、次のようなアプリケーションサーバーが必要になります。 Apache。前述のように環境に追加するか、別の環境に新しく作成することができます。

1. まず、次のボタンをクリックします。 Change Environment Topology そして、サーバーを追加します：

    2. 次のタブを開きます。 Configuration Manager タブ（対象： Apache サーバー）。これを行うには、次のボタンをクリックします。 Config ボタン（下図参照）：

3. 次のディレクトリにあるファイルを見つけて開きます。 index.php ファイル（場所： /var/www/webroot/ROOT ディレクトリ）。デフォルトのコンテンツの代わりに次のコードを貼り付けます：

上記のコード内の以下の値は、それぞれのデータに置き換える必要があります：

• {replica_set_name} – レプリカセット名を入力します。
• {db_username} – 選択したプライマリデータベースの管理者ユーザーを追加します（デフォルトは admin です）。
• {db_password} – 管理者ユーザーのパスワードを入力します。
• {NodeID} – 対応するノードの識別番号を指定します。これは、次の場所で確認できます： CloudSigma PaaS ダッシュボード.
• {environment_domain} – 環境ドメインを追加します。これも CloudSigma PaaS ダッシュボードで確認できます：

レプリカセット内のすべてのノードのIDを、適切な mongodbConnectionURI セクションに指定してください。

対応する値を入力してコードを実行すると、次のような文字列のセットが表示されます：

必ずファイルを 保存（Save） してください！

4. Apache が MongoDB サーバーとやり取りするには、特別なモジュールが必要です。このモジュールは configs 内で追加できます。 etc フォルダに移動して、 php.ini ファイルを開きます。そして、[mongodb] セクションを探します。ここでは、この拡張機能を有効にするために、 extension=mongodb.so 行の前にあるセミコロンを削除するだけです：

      5. エディタウィンドウで「Save 」をクリックして、新しい設定を適用します。いつものように、変更を適用するにはノードを再起動する必要があります。「Restart Nodes 」ボタン（Application Server の横）をクリックして実行します：

    6. 次に「Open in Browser 」ボタンをクリックしてテストします：

このアイコンをクリックすると、新しいブラウザタブが開き、レプリカセットのメンバー/ノードに関するすべての情報と、それらのアクセシビリティが次のように表示されます：

コマンド ping （ の6行目 index.php ）を使用したため、最初の行にはレプリカセットの可用性を確認した結果が表示されます：

これは、レプリカセットのテストが正常に完了したことを意味します。 

結果の次のブロックには、レプリカセットホストに関する詳細情報が表示されます。このデータは、 getServers 関数（ の11行目 index.php）のおかげで取得されます。同様に、このレプリカセットの作成プロセス中に割り当てられたいくつかの値を確認することもできます：

• host – 特定のデータベースのIPアドレス。

• port – これは現在のレプリケーションメンバーのポートです。

• [“is_primary”] および [“is_secondary”] – サーバーのステータスを示すパラメータ。選択したプライマリ MongoDB サーバーの対応する値は true、false であり、他の2つの MongoDB サーバーはそれぞれ – false、true です。

さらに、データベースノードをいつでも起動および停止して、変更を追跡できます。ページを更新して同じことを行うこともできます。これにより、MongoDB クラスターが常に利用可能で、設定通りに稼働していることを確認できます。

CloudSigma PaaS を使用すると、設定やバックエンド側をあまり気にすることなく、レプリカセットを使用するメリットを享受できます。このチュートリアルでは、いくつかの簡単なステップで独自の MongoDB クラスターをいかに簡単にセットアップできるかを示しています。詳細については、MongoDB や、set it up for Ubuntu または public cloud servers へのセットアップ方法、および CloudSigma PaaS が提供するその他の高度な機能についてご覧いただけます。また、take a trial run を利用して、PaaS の dashboard や marketplace 、およびそれらが提供するものに慣れていただくこともお勧めします。 

PaaSを7日間無料で試す