ホームページ >データベース >mysql チュートリアル >MySQL 5.7 の詳細分析: 半同期レプリケーションテクノロジー

MySQL 5.7 の詳細分析: 半同期レプリケーションテクノロジー

一个新手オリジナル: 2017-09-19 09:46:282142ブラウズ

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 に影響します。