この記事では、今後も継続的に改善されるMongoDBレプリカセットの関連知識を中心に紹介します。
1. レプリカセットの構成と紹介
したがって、レプリカ セットは、通常、高可用性を確保するために使用されるデータ冗長ストレージと同じです。次の図は、MongoDB レプリカ セットのアーキテクチャ図を示しています。
( 1)レプリカセットは、同じデータセットを維持するmongodインスタンスのグループです( mongod : mongodbをデプロイするマシンインスタンス) 。
(2)MongoDBレプリカセットの構成。レプリカ セットには、複数のデータ保持ノードとアービトレータノード(オプション)が含まれます。データ保持ノードのうちの 1 つだけのメンバーがプライマリ ノードとみなされ、他のノードはセカンダリ ノードとみなされます。アービター ノードはデータを伝送せず、主に選挙に使用されます。調停ノードは常に調停ノードですが、プライマリ ノードが選出によりセカンダリ ノードになる場合があり、セカンダリ ノードが選出によりプライマリ ノードになる場合もあります。
(3)冗長性と高可用性。レプリカ セットの役割は、冗長性を通じて高可用性を確保することです。冗長ストレージにより、レプリカ セット全体は、単一ノードの非可用性に対して一定の許容度を持ちます。
(4)レプリカ セットのもう 1 つの機能は、読み取り/書き込み戦略(読み取り/書き込み戦略セクションで説明)を構成することによって読み取り拡張を実装することです。
(5)レプリカ セット内のプライマリ ノードは、すべての書き込み操作を受け取ります。プライマリ ノードは、操作ログ( oplog )を通じてすべてのデータ セットの変更操作を記録します( mongodb がプライマリノードにデータを書き込むとき、プライマリノードが配置されているローカルデータベースにもoplogを書き込みます) 。
注: 書き込みリクエストはマスター ノードに直接送信されますが、スレーブ ノードはデータをコピーする必要がありますが、それでもマスター ノードはスレーブ ノードよりも多くのことを行う必要があります。つまり、プライマリ ノードの CPU 使用率がセカンダリ ノードの CPU 使用率よりも高いのは正常です。
2. レプリカセットのハートビート分析
MongoDB レプリカ セットのメンバーは、ハートビートを通じて他のノードの生存ステータスを認識します。通常、レプリカ セットのメンバーは 2 秒ごとにハートビートを相互に送信します。これは通常 ping と呼ばれるものです。通常、10 秒を超えてフィードバックがない場合、ノードは使用不可としてマークされます。10 秒を超えて応答しなかったノードがプライマリ ノードである場合、セカンダリ ノードは、自動フェイルオーバーを実現するためにプライマリ ノードに再投票するための選挙をトリガーします。
関連するコードは主に以下に集中しています。
mongo/db/repl/replication_coordinator_impl_heartbeat.cpp
mongo/src/mongo/db/repl/replication_coordinator_impl.cpp
レプリカ セットの 3 つの最も重要なキー ポイントは、① データ同期、② フェイルオーバー、③ 構成読み取りオプションです。
1. データの同期
シャードされたデータセットの最新のコピーを維持するために、レプリカ セットのセカンダリ ノードは他のメンバーからデータを同期または複製します。MongoDB は 2 つの形式のデータ同期を使用します: 1 つは新しいメンバーに完全なデータ セットを入力する初期化同期で、もう 1 つは oplog を使用したリアルタイム変更の同期です。
1.1. 同期の初期化
初期化同期についてはここではあまり紹介しませんが、実際には完全なコピーです。
1.2. リアルタイム同期
Oplog に関する公式 Web サイトの説明: Replica Set Oplog — MongoDB Manual
1. Oplog の紹介。Oplog (操作ログ) は、Mongodb データベースのすべてのデータ操作レコードを保存するために使用される固定サイズのコレクション (Capped Collection) です (実際には、データベース データを変更する操作レコード (つまり、追加/削除/変更) のみを記録します)。類推すると、これは mysql の binlog ログに相当します。
Oplog の存在により、MongoDB レプリカ セットの各ノードのデータ同期が大幅に容易になります。
2. レプリカセットのデータ同期のプロセス。
プロセスは大まかに次のとおりです:プライマリノードがデータを書き込んだ後、セカンダリノードはローカルデータベースのoplogt.rsコレクションをチェックして、データが十分に新しいことを確認するために最新のレコードのタイムスタンプを見つけます。Pirmaryのoplog.rsをクエリします。このセットは、このタイムスタンプより大きいレコードをすべて検索し、操作レコードを独自のoplogに書き込み、これらのレコードで表される操作を実行します。①すべてのレプリカ セット メンバーは oplog のコピーを持ちます。 ② oplog 内の各操作は冪等であり、一部の操作が 2 回以上同期されても悪影響はありません。③レプリケーション効率を向上させるために、レプリカセット内のすべてのノードは相互にハートビート検出 (ping) を実行し、各ノードは他のノードから oplog を取得できます。④ mongodb は、oplog.rs をキャップ付きタイプのコレクション、つまり、合理的な固定サイズに設定します; ⑤ ただし、長時間ダウンしていたノードの場合、セカンダリ ノードは最新のタイムスタンプを使用して、この場合、データを手動で再同期する必要があります。⑥ oplog のサイズが非常に重要であることがわかります。
注: キャップされたコレクションの場合は、循環キューと考えてください。コレクション領域が使い果たされると、要素を挿入すると最初の head 要素が上書きされます。
マスターとスレーブの同期には、独自の多くの詳細があります。ただし、一般に、oplog をプルして再生することは、「単一のプロデューサーと複数のコンシューマー」のプロデューサー/コンシューマー モデルとして理解できます。これらは相互に独立しており、通常の状況では相互にブロックされません。コードの詳細については、勉強する機会を設けてください。
1.3. 同期遅延解析
問題: 負荷が大きすぎると、mongodb のマスターとスレーブの同期に大幅な遅延が発生し、最新のデータを読み取れなくなる場合があります。
この種の遅延は、通常の使用シナリオではほとんど感知できません。たとえば、手動テスト中にデータの不整合は発生しません。さらに、Tencent Cloud のマスター/スレーブ遅延監視は、第 2 レベルをはるかに下回ります (おそらくミリ秒程度のみ)。 ）。ただし、書き込み負荷が特に大きい場合は、より明らかな遅延が発生する可能性がありますが、50k/分の書き込み量では明らかな遅延はほとんどありません。mongodbでは、これはまったく問題ではありません。CAP理論では、一貫性、可用性、およびパーティション許容度は 3 つのうち 2 つまでしかあり得ないと判断されているためです。ほとんどのデータ分散データベースでは、A (可用性)とP (パーティション許容度)が選択されます。 C (一貫性) を放棄し、要求の少ない最終的な一貫性を選択します。
注: CAP 理論の C (一貫性) は、線形一貫性 (強い一貫性) を指し、最終的な一貫性 (弱い一貫性) に対応します。
mongodb は、マスターとスレーブのさまざまな側面でのデータの一貫性に加えて、読み取りと書き込みのデータの一貫性、およびメモリ/ディスクの次元でのデータの一貫性も備えています。話せそうな気がする。
3. Oplog のデフォルトのサイズ
レプリカ セット メンバーを初めて起動するときに、oplog を指定しない場合、mongodb はデフォルトのサイズで oplog を自動的に作成します。Unix および Windows システムの場合、デフォルトの oplog のサイズは次のようにエンジンによって異なります。
| ストレージエンジン | デフォルトの Oplog サイズ | 下限 | 上界 |
|---|---|---|---|
| インメモリ | 物理メモリの 5% | 50MB | 50GB |
| ワイヤードタイガー | 空きディスク容量の 5% | 990MB | 50GB |
| MMAPv1 | 空きディスク容量の 5% | 990MB | 50GB |
ほとんどの場合、デフォルトの oplog サイズで十分です。たとえば、oplog が利用可能なディスク領域の 5% を占有し、24 時間の操作でいっぱいになる場合、レプリカ ノードは oplog からデータをコピーせずに 24 時間を達成でき、最終的な同期 (レプリカ ノードのダウンタイムなど) には影響しません。 。ほとんどのレプリカ セットは操作負荷がはるかに低く、その oplog にはさらに多くの操作を保持できます。
通常、システムに次の操作が存在する場合、データの損失を避けるために、より大きな Oplog 値を設定する必要がある場合があります。
①一度に大量のデータを更新する ②フィールドを削除し、ほぼ同量のデータを挿入する ③大量の既存データを更新する
4. oplogの共通コマンド
(1) oplog のステータスを表示します。
rs.printReplicationInfo()
(2) oplog ストレージ設定のサイズを表示する
ローカルを使用する
db.oplog.rs.stats().maxSize
(3) oplog の最大サイズ、現在の占有サイズ、および記録期間を表示します。
db.getReplicationInfo()
(4) レプリカセットメンバーの Oplog サイズを変更する
db.adminCommand({replSetResizeOplog: 1, サイズ: 15000})
注意点：
(1) シャーディング アーキテクチャでは、mongo は oplog を表示できませんが、各 mongod インスタンスにアクセスして oplog を表示できます。
さらに、上記のコマンドの多くは単一の mongo インスタンスでは使用できません (レプリカ セットが検出されなかったというメッセージが表示されます)。
同様のゲームプレイ:
Redis でのプレイ方法:
実はこのゲームプレイとredisのAOF永続化は全く同じ考え方で、AOF永続化とはサーバーが処理したデータ変更操作をログの形で記録し、データ復旧のためにredisがハングアップした場合に備えて、まずRDBを復元するというものです。永続性 ダウンロードされたバイナリは圧縮されて保存され、書き込み、追加、削除、および変更操作を再現する機会として使用されます。
mysqlで遊ぶ方法:
MySQL のバイナリ ログ binlog は、MySQL の最も重要なログと言え、すべての DDL および DML ステートメント (データ クエリ ステートメント select や show などを除く) をイベント形式で記録し、ステートメントの実行に費やされた時間も含まれます。 . MySQL バイナリ ログはトランザクションに対して安全です。バイナリログの主な目的は、レプリケーションとリカバリです。Binlog ログの 2 つの最も重要な使用シナリオ
①MySQL マスター/スレーブ レプリケーション: MySQL レプリケーションはマスター側で binlog を開き、マスターはそのバイナリ ログをスレーブに渡してマスター/スレーブ データの一貫性の目的を達成します。 ② データ リカバリ: mysqlbinlog ツールを使用し
ます。リカバリーデータを作るため