mysql のマスター/スレーブ同期と非同期の使用シナリオを分析する

この調査を実施する理由は主に、以前に遭遇した 2 つの未解決の疑問に対処するためです。

a．オンラインのシステムがあるのですが、準同期状態から準同期状態になり、すぐに準同期状態に戻ることがよくありますが、具体的な原因は不明で、以前から推測はしていましたが、よくわかりません。

b．少し前に、ビジネス シナリオの要件により、マシン ルーム間の非同期レプリケーション テストを実施しました。 mysql write qps が非常に高い場合、多くのログがスレーブ ライブラリに送信される時間がないことがわかります。つまり、メイン ライブラリでの binlog ログの生成速度がスレーブ ライブラリへの送信速度よりも速いことがわかります。この速度差は常に存在するため、メイン ライブラリの負荷が高い状態が続くと、バイナリ ログが生成されると、スレーブ ライブラリに送信されないビンログが増えますが、その時のネットワーク トラフィックはわずか 18M/S 程度でした (従来の知識によれば、ギガビットネットワークの伝送速度は100Mに達しますが、現在のマスターとスレーブ間のビンログ伝送速度は18M程度しかありません。その理由は何ですか?ネットワークの問題ですか?あるいは他の理由で。

マスター/スレーブ レプリケーションの原理 ダンプ スレッドと IO スレッド マスターとスレーブのレプリケーション関係が確立されると、マスター ライブラリ上にダンプ スレッドが存在します。これはマスター ライブラリで生成されたバイナリ ログを送信するために使用され、スレーブ ライブラリ上の IO スレッドはバイナリ ログを受信するために使用されます。ダンプ スレッドによってネットワーク経由でスレーブに送信されるデータ ライブラリのバイナリ ログであり、それをリレー ログに書き込む役割を果たします。これがマスタ・スレーブ型レプリケーションの仕組みであると同時に、非同期レプリケーションであるため、送信処理にack確認が不要です。

ここでも質問があります。非同期送信であるため、単純に binlog ファイルの直接ネットワーク送信として理解すると、速度は非常に高速になるはずですが、実際の状況: テスト環境では、binlog の送信速度はログの速度はわずか 18M/s であり、ログによって生成される速度約 22M/s よりも遅いです。この速度だけでネットワーク帯域幅を使い切っていないのはなぜですか?理由は何ですか？

ログ配信の詳細 マスター/スレーブ レプリケーション構造では、マスター ライブラリに 1 つのダンプ スレッド、スレーブ ライブラリに 1 つの IO スレッドがあるため、複数のスレッドの同時送受信はありません。 binlog ダンプ スレッドすべての詳細を理解できます。

バイナリログ ファイルを解析すると、トランザクションに複数のイベントが含まれる可能性があることがわかります。最も単純なもののバイナリログに記録される情報は次のとおりです:

リーリー

xxxxx の各セグメントはイベントです。

関数 Binlog_sender::send_events は、イベント イベントを binlog:

で送信する関数です。

関数パラメータ: end_pos、現在読み取られているbinlogファイルの終了位置。

log_cache、レコードは、送信された binlog ログの場所と binlog ログ ファイルを含む、現在送信されているログの情報です。

関数ロジック分析: 現在送信位置 log_pos が取得したファイルの終了位置 end_pos より小さい場合は、未送信の binlog ログがまだ存在することを示し、ループに入ります。

ループ本体:

a. まず関数 read_event を呼び出して、イベントeventを取得します。

b. ログイベントタイプevent_type= (ログイベントタイプ)event_ptr[EVENT_TYPE_OFFSET];

このステートメントは、イベントのタイプを取得し、タイプ チェックを実行するために使用されます

check_event_type(event_type, log_file, log_pos), チェックが通らなかった場合は、上位関数に直接 1 が返されます。

c. log_pos= my_b_tell(log_cache); log_pos の位置を更新します、つまり、binlog の位置を読み取るカーソルを現在の位置まで前方に移動します。

d. 次に、send_packet() 関数を呼び出してバイナリログを送信します。

現在スレーブ ライブラリに同期されていないビンログの数に関係なく、マスター ライブラリによって送信されるビンログの粒度は依然としてイベントを 1 つずつ送信することであることがわかりました。送信する前に、イベントのタイプを次のとおりにする必要があります。チェックした。小さなパケットで送信されるため、ネットワーク トラフィックは大きくなりません。

ただし、この現象の前提条件を説明する必要があります: 私たちのテスト環境では、その時点でデータベースの書き込み QPS が 50,000 を超えていたため、送信する必要があるイベントが多数ありました。非同期の場合、シングルスレッドのダンプ スレッドには送信する時間がありませんでした。現在のログが生成されました。

書き込まれたQPSが巨大な場合、ログの送信が遅すぎる状況が発生する可能性があります。

要約

ここで、オンライン上で発生した問題を振り返ってみましょう。「同期状態が準同期状態から非同期状態に変化し、時間が経つと準同期状態に戻ることがよくある。」データベースは分析システムであり、バッチ更新やバッチインポートが行われる場合があります。同時に、データベースによって設定されたバイナリ ログ形式は行モードであり、複数の行を更新するトランザクションの場合、多くのイベント (1 行がイベント) が含まれるため、このトランザクションのバイナリ ログの送信には長い時間がかかり、送信できません。完了（準同期タイムアウトが 1 に設定）されるため、準同期状態は非同期になります。

以上がmysql のマスター/スレーブ同期と非同期の使用シナリオを分析するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。