MySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジー
- 一个新手オリジナル
- 2017-09-19 09:46:282095ブラウズ
MySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジ
レプリケーション アーキテクチャの歴史
この機能について説明する前に、まず MySQL のレプリケーション アーキテクチャの歴史を見てみましょう。 MySQL レプリケーションは、
通常のレプリケーション、非同期、同期の 4 つのタイプに分類されます。 このアーキテクチャは構築が簡単で、MySQL の誕生以来作られており、非常に完成度が高いと言えます。 ただし、このアーキテクチャのデータは非同期であるため、データベースが失われるリスクがあります。
準同期レプリケーション、準同期。パフォーマンスと機能は、非同期と完全同期の間のどこかにあります。上記 2 つのアーキテクチャのパフォーマンス、長所、短所を妥協するために、mysql5.5 から誕生しました。
同期レプリケーション、完全同期。現在、グループ レプリケーションに基づく公式 5.7 完全同期テクノロジはラボ バージョンにあり、正式な統合にはそう遠くありません。完全同期テクノロジーにより、データの一貫性がさらに保証されます。これは今後の同期技術の重要な方向性であり、期待に値すると思います。
mysql クラスター。 NDB エンジンをベースにしており、構築が簡単で比較的安定しています。MySQL のデータ保護において最も信頼性の高いアーキテクチャであり、現在、完全なデータ同期とゼロのデータ損失を備えた唯一のアーキテクチャです。しかし、私は仕事にこだわりがあり、制約が多いです。
準同期レプリケーション
今日は 2 番目のアーキテクチャについて話します。通常のレプリケーション、つまり mysql の非同期レプリケーションは、データ レプリケーションのために mysql バイナリ ログ、つまりバイナリ ログに依存していることがわかっています。たとえば、2 台のマシンがあり、1 台はマスター、もう 1 台はスレーブです。
通常のレプリケーションは、トランザクション 1 (t1) が binlog バッファに書き込まれ、ダンパー スレッドが新しいトランザクション t1 があることをスレーブに通知し、binlog バッファがチェックポイントを実行して t1 を書き込みます。独自のリレー ログ。スレーブの SQL スレッドはローカル データベースに書き込みます。 現時点では、マスターとスレーブの両方がこの新しいトランザクションを確認できます。マスターが死亡した場合でも、スレーブは新しいマスターに昇格できます。
異常なコピーは次のとおりです: トランザクション 1 (t1) が binlog バッファに書き込まれ、ダンパー スレッドがスレーブに新しいトランザクション t1 が通知され、binlog バッファが不安定なため t1 を受信しませんでした。ネットワークが切断され、スレーブが新しいマスターに昇格し、t1 が失われます。
大きな問題は、マスターとスレーブのトランザクションの更新が同期していないことです。ネットワークやその他のシステムに異常がない場合でも、ビジネスが並行している場合、スレーブはマスター バッチ トランザクションを順番に実行する必要があり、その結果、膨大な量のトランザクションが発生します。遅れ。 。
上記のシナリオの欠点を補うために、mysql は 5.5 から準同期を開始しました。つまり、マスターのダンパースレッドがスレーブに通知した後、t1 のフラグコードが正常に受信されたかどうかの ack が追加されます。つまり、ダンパー スレッドは、t1 をスレーブに送信することに加えて、スレーブの ACK を受信する責任もあります。例外が発生し、ACK が受信されない場合、例外が修復されるまで、自動的に通常のレプリケーションにダウングレードされます。
準同期によってもたらされる新たな問題がわかります:
例外が発生すると、通常のレプリケーションにダウングレードされます。 これにより、スレーブ マシン上のデータの不整合の可能性は減少しますが、完全に排除されるわけではありません。
ホスト ダンパー スレッドはより多くの作業を必要とするため、明らかにデータベース全体のパフォーマンスが低下します。
MySQL 5.5 および 5.6 で使用される MySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジー モードでは、つまりスレーブがトランザクションを受信しない場合、つまりトランザクションがリレー ログに書き込まれる前に、ネットワークが異常または不安定になり、マスターがこの時点で電話が切れ、システムがスレーブ マシンに切り替わると、双方のデータが不整合になります。 この場合、スレーブのトランザクション データは 1 つ少なくなります。
MySQL 5.7 のリリースにより、準同期レプリケーション テクノロジーは新しいロスレス準同期レプリケーション アーキテクチャにアップグレードされ、その成熟度、データの一貫性、実行効率が大幅に向上しました。
MySQL 5.7 でのデータ レプリケーション効率の向上
マスターとスレーブの一貫性が強化され、トランザクション コミット前の ACK の待機をサポート
新しいバージョンの半同期では、半同期モードでマスター データベースを制御するための rpl_semi_sync_master_wait_point パラメーターが追加されていますセッショントランザクションが成功する前にトランザクションをコミットする方法に戻るとき。
このパラメータには 2 つの値があります:
-
AFTER_COMMIT (5.6 のデフォルト値)
マスターは各トランザクションを binlog に書き込み、それをスレーブに渡してディスク (リレー ログ) にフラッシュします。メイン ライブラリがトランザクションをコミットします。マスターは、リレー ログを受信するためにスレーブのフィードバックを待ちます。マスターは、ACK を受信した後でのみ、コミット OK の結果をクライアントにフィードバックします。
-
AFTER_SYNC (5.7のデフォルト値、ただしこのモードは5.6では利用できません)
マスターは各トランザクションをbinlogに書き込み、それをディスク(リレーログ)にフラッシュするためにスレーブに渡します。マスターは、スレーブのフィードバックがリレー ログの確認応答を受信するのを待った後、トランザクションを送信し、コミット OK の結果をクライアントに返します。 メイン ライブラリがクラッシュした場合でも、メイン ライブラリでコミットされたすべてのトランザクションはスレーブのリレー ログに同期されることが保証されます。
したがって、5.7 では MySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジー モードが導入されました。その主な利点は、MySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジー によって引き起こされるマスター間のデータの不一致の問題を解決することです。したがって、MySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジー モードの導入後、送信されたデータはすべてコピーされます。フェイルオーバー中のデータの一貫性が向上します。
パフォーマンスの向上、非同期のバイナリ送信とACKの受信のサポート
古いバージョンの半同期は、ダンプスレッドが2つの異なる非常に頻繁なタスクを実行するため、ダンプスレッドによって制限されます: バイナリログをスレーブに送信し、待機する必要もありますスレーブ フィードバック情報用であり、2 つのタスクはシリアルです。ダンプ スレッドは、次のイベント トランザクションを送信する前にスレーブが戻るのを待つ必要があります。ダンプ スレッドは、準同期全体のパフォーマンスを向上させるボトルネックになっています。同時実行性の高いビジネス シナリオでは、このようなメカニズムはデータベース全体の TPS に影響します。
上記の問題を解決するために、半同期フレームワークの 5.7 バージョンでは、スレーブからフィードバック情報を受信するために特別に使用される独立した ACK コレクター スレッドが作成されます。このように、マスター上には独立して動作する 2 つのスレッドがあり、ビンログをスレーブに送信し、同時にスレーブからフィードバックを受信できます。
パフォーマンスの向上、メイン ライブラリによって受信されるスレーブ書き込みトランザクション成功フィードバックの数を制御
MySQL 5.7 では、rpl_semi_sync_MySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジー パラメーターが追加され、メイン ライブラリが受け入れるスレーブ書き込みトランザクション成功フィードバックの数を制御するために使用できます。 、高可用性アーキテクチャへの切り替え 柔軟性を提供します。
図に示すように、カウント値が 2 の場合、マスターは 2 つのスレーブからの ACK を待つ必要があります。
パフォーマンスの向上、ビンログミューテックスの改善
半同期レプリケーションの古いバージョンでは、メイン送信のバイナリログ書き込みセッションとバイナリを読み取るダンプスレッドのビンログにミューテックスロックが追加され、バイナリログファイルの読み取りと書き込みが発生します。はい、同時実行の問題があります。
MySQL 5.7 は、次の 2 つの側面で binlog ロックを最適化しました:
1. binlog のダンプ スレッドのミューテックス ロックを削除しました
2. binlog の読み取りの安全性を確保するために安全マージンを追加しました
パフォーマンス プロモーション、グループ提出
MySQL 5.7 では、新しい変数 SLAVE-Parallel-type が導入されており、その設定可能な値は次のとおりです:
1. DATABASE (5.7 より前のデフォルト値)、ライブラリベースの並列レプリケーション メソッド
2. ( 5.7 の新しい値)、グループ送信に基づく並列レプリケーション方法。
MySQL バージョン 5.6 もいわゆる並列レプリケーションをサポートしますが、その並列処理は DATABASE、つまりライブラリにのみ基づいています。ユーザーの MySQL データベース インスタンスに複数の DATABASE がある場合、実際にスレーブ レプリケーションの速度に大きく役立ちます。ユーザー インスタンスにデータベースが 1 つしかない場合、並列再生は実現できず、パフォーマンスはさらに悪くなります。元の単一スレッドの違い。
新しい並列モードが MySQL 5.7 に追加されました。同時に COMMIT フェーズに入るトランザクションには同じシーケンス番号が割り当てられます。同じシーケンス番号を持つこれらのトランザクションは、スタンバイ データベースで同時に実行できます。
MySQL 5.7 は実際に並列レプリケーションを実装しています。その主な理由は、スレーブ サーバーの再生がホストの再生と一致しているためです。つまり、マスター サーバーでの並列実行はスレーブでの並列再生と同じです。ライブラリベースの並列レプリケーションに対する制限はなくなり、バイナリ ログ形式に対する特別な要件もありません (ライブラリベースの並列レプリケーションの要件もありません)。
したがって、次のシーケンスで同時実行できるシーケンスは次のとおりです (最初の番号は last_committed で、次の番号は sequence_number です):
trx1 1…..2 trx2 1………….3 trx3 1…………………….4 trx4 2……………………….5 trx5 3…………………………..6 trx6 3………………………………7 trx7 6………………………………..8
スタンバイ データベースの並列ルール: トランザクションが分散されるとき、その last_committed シーケンス番号は、現在実行中のトランザクション トランザクションの最小 sequence_number が 1 時間未満の場合、実行が許可されます。したがって、
1. trx1 が実行されると、last_commit 2. trx1 が実行された後、last_commit 3. trx2が実行された後、last_commit 4. trx3、trx4、trx5が完了した後、last_commit
MySQL バージョン 5.7 は半同期レプリケーションであると考えています。テクノロジーの最適化により、その成熟度と実行効率が定性的に向上しました。 MySQL 5.7 を実稼働環境のデプロイメントとして使用する場合、高可用性と読み取り/書き込み分離のためのデータ レプリケーション ソリューションとして半同期テクノロジを使用できることをお勧めします。
以上がMySQL 5.7 の詳細分析: 半同期レプリケーション テクノロジーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。