チェーンレプリケーションとは何ですか？
レプリケーションについて話すときは、データの可用性に関する設計基準を満たすために、データの冗長コピーを作成するプロセスを指します。したがって、チェーンレプリケーションとは、同期されたチェーンを形成するためのMongoDBサーバーの線形順序付けを指します。チェーンにはプライマリノードが含まれ、線形に配置されたセカンダリサーバーがそれに続きます。ワードチェーンが示唆するように、プライマリサーバーに最も近いサーバーはそこから複製し、後続の他のすべてのセカンダリサーバーは先行するセカンダリMongoDBサーバーから複製します。これが、チェーンレプリケーションと通常のレプリケーションの主な違いです。連鎖レプリケーションは、セカンダリノードがping時間を使用してターゲットを選択した場合、または最も近いノードがセカンダリである場合に発生します。チェーンレプリケーションは表示どおりですが、プライマリノードの負荷は軽減されますが、レプリケーションの遅延が発生する可能性があります。
チェーンレプリケーションを使用する理由
システムインフラストラクチャは、サーバーの損失につながる予期しない障害に見舞われ、その結果、可用性に影響を与えることがあります。レプリケーションにより、予測できない障害が可用性に影響を与えないことが保証されます。レプリケーションにより、ハードウェア障害やサービスの中断からの回復がさらに可能になります。チェーンレプリケーションと非チェーンレプリケーションはどちらも、システム障害が発生しても可用性を確保するというこの目的を果たします。レプリケーションが重要であることを確認したら、特にチェーンレプリケーションを使用する理由を尋ねることができます。 MongoDbでは、チェーンレプリケーションと非チェーンレプリケーションの間にパフォーマンスの違いはありません。どちらの場合も、プライマリノードに障害が発生すると、セカンダリサーバーは新しい動作のプライマリに投票するため、どちらの場合もデータの書き込みと読み取りは影響を受けません。ただし、連鎖レプリケーションは、MongoDbのデフォルトのレプリケーションタイプです。
チェーンレプリカを設定する方法
デフォルトでは、連鎖レプリケーションはMongoDBで有効になっています。したがって、チェーンレプリケーションを非アクティブ化するプロセスについて詳しく説明します。チェーンレプリケーションを無効にできる主な理由は、ラグが発生している場合です。ただし、チェーンレプリケーションのメリットはラグデメリットよりも優れているため、ほとんどの場合、非アクティブ化する必要はありません。チェーンレプリケーションがデフォルトでアクティブになっていない場合に備えて、次のコマンドがアクティブ化に役立ちます。
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)このプロセスは元に戻すことができます。チェーンレプリケーションを非アクティブ化するように強制されると、次のプロセスが忠実に実行されます。
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)チェーンレプリケーションのヒントとコツ
チェーンレプリケーションの最も恐ろしい制限は、レプリケーションの遅延です。レプリケーションラグとは、プライマリで操作が実行されてからセカンダリで同じ操作がレプリケートされるまでの間に発生する遅延を指します。当然のことながら不可能ですが、その複製ラグで複製速度を非常に速くすることが常に望まれます。レプリケーションラグを回避または最小化してゼロに近づけるには、CPU、RAM、IO、およびネットワーク関連の仕様に関して同じ仕様のプライマリホストとセカンダリホストを使用することが賢明な設計基準です。
チェーンレプリケーションはデータの可用性を保証しますが、チェーンレプリケーションはジャーナリングと一緒に使用できます。ジャーナリングは、定期的にディスクにフラッシュされるログに書き込むことにより、データの安全性を提供します。 2つを組み合わせると、書き込み要求ごとに3つのサーバーが書き込まれます。これは、書き込み要求ごとに2つのサーバーのみが書き込まれるチェーンレプリケーションのみの場合とは異なります。
もう1つの重要なヒントは、wをレプリケーションで使用することです。 wパラメーターは、成功を返す前に応答を書き込む必要があるサーバーの数を制御します。 wパラメータが設定されている場合、getlasterrorはサーバーのoplogをチェックし、指定された数の「w」サーバーに操作が適用されるまで待機します。
MongoDB Monitoring Service（MMS）やClusterControlなどの監視ツールを使用すると、レプリカノードのステータスを取得し、時間の経過に伴う変化を視覚化できます。たとえば、MMSでは、レプリケーションラグタイムの変動を示すセカンダリノードのレプリカラググラフを見つけることができます。
チェーンレプリケーションのパフォーマンスの測定
ここまでで、チェーンレプリケーションの最も重要なパフォーマンスパラメータはレプリケーションのラグタイムであることに気づきました。したがって、レプリケーションラグ期間をテストする方法について説明します。このテストは、MongoDbシェルスクリプトを介して実行できます。レプリケーションラグテストを実行するために、プライマリノードの最後のイベントのoplogとセカンダリノードの最後のイベントのoplogを比較します。
プライマリノードの情報を確認するには、次のコードを実行します。
db.printSlaveReplicationInfo()上記のコマンドは、プライマリノードでの最近のすべての操作に関する情報を提供します。結果は次のように表示されます。
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)プライマリのoplogを取得したので、セカンダリノードのoplogに関心があります。次のコマンドは、oplogを取得するのに役立ちます。
db.printReplicationInfo()このコマンドは、oplogサイズ、ログの長さ、oplogの最初のイベントの時間、oplogの最後のイベントの時間、および現在の時間の詳細を出力に提供します。結果は次のように表示されます。
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)プライマリサーバーのoplogから、最後の同期は2013年3月5日火曜日07:48:19 GMT-0800（PST）に発生しました。セカンダリサーバーのoplogから、最後の操作は2013年3月5日火曜日07:48:19 GMT-0800（PST）に発生しました。レプリケーションラグはゼロであったため、チェーンレプリケートシステムは正しく動作しています。ただし、複製のタイムラグは、複製する必要のある変更の量によって異なる場合があります。