3.4.6. MongoDB レプリケーション
データベースイメージのクラスターリングを有効にする設定はサンプルとして提供され、実稼働環境での使用を目的としていません。
Red Hat は、StatefulSet を使用した MongoDB のレプリケーション (クラスターリング) 用に、概念実証 テンプレート を提供します。GitHub からサンプルテンプレート を取得できます。
たとえば、現在のプロジェクトのテンプレートライブラリーにテンプレートのサンプルをアップロードするには、以下を実行します。
$ oc create -f \
https://raw.githubusercontent.com/sclorg/mongodb-container/master/examples/petset/mongodb-petset-persistent.yaml以下のテンプレートサンプルでは、永続ストレージを使用します。このテンプレートを使用するには、クラスターで永続ボリュームが利用できるようにする必要があります。
OpenShift Container Platform は正常でない Pod(コンテナー) を自動的に再起動するので、レプリカセットのメンバーの 1 つ以上がクラッシュまたは失敗すると、レプリカセットメンバーは再起動されます。
レプリカセットメンバーがダウンまたは再起動している間は、以下のいずれかのシナリオになります。
プライマリーメンバーがダウンしている。
この場合、他の 2 つのメンバーが新しいプライマリーを選択します。それまでは、読み取りには影響はありませんが、書き込みは失敗します。正常に選択された後は、書き込みおよび読み取りは通常通りに処理されます。
セカンダリーメンバーの 1 つがダウンしている。
読み取りおよび書き込みには影響はありません。
oplogSize設定と書き込み速度によっては、3 つ目のメンバーがレプリカセットへの再度の参加に失敗する可能性があるため、手動の介入によりデータベースのコピーをもう一度同期する必要があります。任意の 2 つのメンバーがダウンしている。
3 つのメンバーで設定されるレプリカセットメンバーが他のメンバーに到達できない場合には、プライマリーロールが指定されていれば、そのロールが取り消されます。この場合、読み取りはセカンダリーメンバーが行う可能性があり、書き込みは失敗します。もう 1 つのメンバーが再度起動したらすぐに、新しいプライマリーメンバーが選択され、読み取りおよび書き込みが通常通りに処理されます。
すべてのメンバーがダウンしている。
このように極端なケースでは、読み取りおよび書き込みの両方が失敗します。2 つ以上のメンバーが再度起動すると、レプリカセットにプライマリーとセカンダリーメンバーが含まれるように選択が行われ、その後に読み取りと書き込みが通常通りに処理されます。
これは MongoDB に推奨されるレプリケーションストラテジーです。
実稼働環境では、できるだけメンバー間の分離を維持する必要があります。StatefulSet Pod を異なるノードにスケジュールするために 1 つ以上のノード選択機能を使用し、個別のボリュームでサポートされるストレージを提供することが推奨されます。
3.4.6.1. 制限
- MongoDB 3.2 のみがサポートされます。
- スケールダウンの場合は、レプリカセットの設定を手動で更新する必要があります。
ユーザーおよび管理者のパスワードの変更は、手動のプロセスで行います。以下が必要です。
- StatefulSet 設定の環境変数の値の更新
- データベースのパスワードの変更
- すべての Pod を次々に再起動します。
