MongoDBレプリカセットの構築

MongoDBレプリカセット(Replica Set)は、1つのPrimaryノードと1つ以上のSecondaryノードからなる自動フェイルオーバ機能を持つプライマリ・スレーブ・クラスタです.レプリカセットの動作モードは次の図です.
レプリカ・セットのデータ同期プロセス:
Primaryノードはデータを書き込み、SecondaryはPrimaryのoplogを読み取ることでコピー情報を得て、データのコピーを開始し、コピー情報を自分のoplogに書き込む.操作に失敗した場合、バックアップノードは現在のデータ・ソースからのデータのコピーを停止します.あるバックアップノードが何らかの理由でオフになった場合、再起動すると自動的にoplogの最後の操作から同期が開始され、同期が完了すると、自分のoplogに情報が書き込まれます.コピー操作はまずデータをコピーし、コピーが完了してからoplogに書き込むため、同じ操作が2部同期する可能性がありますが、MongoDBは設計当初からこの問題を考慮してoplogの同じ操作を複数回実行していました.一度実行する効果と同じです.
簡単に言えば、
 
Primaryノードがデータ操作を完了すると、Secondaryは一連の動作を行い、データの同期を保証する:1:自分のlocalライブラリのoplogをチェックする.rs集合は最近のタイムスタンプを見つけます.2:Primaryノードlocalライブラリoplogを確認します.rsセットで、このタイムスタンプより大きいレコードを見つけます.3:見つかったレコードを自分のoplogに挿入する.rsコレクションでは、これらの操作を実行します.
環境構築(以下linuxシステム、windowsシステム同理)
1:インストールプログラムをダウンロードします.アドレスは次のとおりです.https://www.mongodb.org/downloads必要に応じて適切なバージョンをダウンロード
2:解凍してbinディレクトリに入り、プロファイルを作成します(そうでなければ起動するたびに各パラメータを入力します):mongode.conf
構成内容を入力します(参考までに、各パラメータは実際のニーズで調整してください):
構成パラメータ## net:   port: 27017 ## systemLog:     destination: file     path:  "mongod.log"     logAppend:  true storage:     ##     engine: wiredTiger     ##     dbPath: /home/soft/mongodb-3.2.1/data     ## ， ，     journal:        enabled:  true   #enable at production     wiredTiger:        engineConfig:           cacheSizeGB: 1           statisticsLogDelaySecs: 3600           journalCompressor: snappy           directoryForIndexes:  true        collectionConfig:           blockCompressor: snappy        indexConfig:           prefixCompression:  true processManagement: ##     fork:  true replication:    ## oplog    oplogSizeMB: 2048    ##    replSetName: candao_qc    secondaryIndexPrefetch: all    enableMajorityReadConcern:  false
(起動前にdbPath:/home/soft/mongodb-3.2.1/dataというディレクトリが作成されたことを覚えています)
3:他の2台のサーバ(公式推奨レプリカセットのメンバーは3または奇数)を同様に構成し、それぞれ実行します./mongod -f mongod.confはmongodbを起動します.このとき各機器は依然として単機モードでありmongoプログラムを実行して初期化する必要がある(しかもこのように初期化するしかない)
4:いずれかのサーバで実行します./mongo入力コマンド:
レプリカセットの初期化var   conf = {    "_id" : "candao_qc" ,     members : [{      "_id" :0, // ID      "host" : "192.168.86.73:27017" , // IP      "priority" :1, // ( ， 1)    },...] } rs.initiate(conf);   // Mongo primary priority ， primary ， primary， primary ， priority ， primary. // ， ，
詳細な構成パラメータについては、次の項目を参照してください.https://docs.mongodb.org/manual/reference/replica-configuration/
5:rs.status()を入力してレプリカセットのステータスを表示します.エラーがなければ、レプリカセットが短時間で初期化に成功し、通常の出力は次のようになります.
レプリカセットの構成情報を変更する必要がある場合があります.手順は次のとおりです.
   1.ホスト上でmongoプログラム2を実行する.var conf=rs.conf()を入力します.   3.conf.members[n]={......各種jsonパラメータ}//は初期化と同様に修正する.rs.reconfig(conf, {force:true});   5.rs.status()レプリカセットのステータスの表示、変更に成功したかどうか
mongoの数字は0から始まり、javaの開始位置と同じです.
 
に注意
レプリケーション・セットの実行中に、レプリケーション・セットのバージョンのアップグレード、ノードのメンテナンスなど、ノードを再起動する必要があるシーンに遭遇することは避けられません.ノードを再起動する過程で、 shutdown Primaryを提案します.これにより、 primary secondary になる可能性があります.

shutdown Primary(shutdownはSecondary oplogが10 s以内に追いつくのを待つ)

Primaryが終了すると、残りのノードは新しいPrimary(レプリケーションセットは1または2ノード例外のみを含む)

を選出する.

Primaryは、現在のレプリケーションセットに新しいPrimaryがあるため、このPrimaryはSecondaryのロールで実行されます.

新しいPrimary同期の過程から、自分が oplogを持っていることに気づき、rollbackを先に行います.(rollbackのデータは300 Mを超えなければ取り戻せる)

データを失わずに複製セットを再起動したい場合は、より優雅に開く方法が必要です.

複製セット内のすべてのSecondaryノード

を1つずつ再起動する

PrimaryにstepDownコマンドを送信し、primaryがSecondary

に降格するのを待つ

ダウングレード後のPrimary

を再起動
注意:Secondaryの同期がPrimaryに追いつかない場合、ステップ2が失敗する可能性があります.この場合、stepDownが成功するまでステップ2を再試行する必要があります.ステップ2はまた、replsetReconfigコマンドを呼び出してノード優先度を調整することによって、Secondaryがより高い優先度を持つようにし、PrimaryがSecondaryに降格するのを待つこともできる.
したがって、接続レプリケーションセットはPrimaryに直接接続しないでください.そうしないと、ノードロールの切り替え時にエラーを正しく許容できず、サービスが高いことは保証されません.
 

# 

mmm:PRIMARY> use admin

switched to db admin

mmm:PRIMARY> db.shutdownServer()