MySQL並列レプリケーションの簡単な説明

1. 並列レプリケーションの背景

まず、並列レプリケーションの概念はなぜ存在するのでしょうか?

1. DBA は、MySQL レプリケーションが binlog に基づいていることを知っておく必要があります。

2. MySQL レプリケーションは、IO スレッドと SQL スレッドの 2 つの部分で構成されます。

3. IOスレッドは主に受信マスターから渡されたバイナリログを取得し、リレーログに書き込むために使用されます。

4. SQLスレッドは主にリレーログを解析し、それをスレーブに適用する役割を担う。

5. いずれにしても、IO スレッドと SQL スレッドはシングルスレッドですが、マスターはマルチスレッドなので、遅延は避けられません。この問題を解決するために、マルチスレッドが生まれました。

6. IO マルチスレッド?

6.1 IO スレッドがボトルネックではないため、IO のマルチスレッド化は必要ありません。

7. SQL マルチスレッド?

7.1 はい、最新の 5.6、5.7、および 8.0 はすべて、スレーブの同時実行性を向上させるために SQL スレッドでマルチスレッドを実装しています。

次に、並列レプリケーションにおけるMySQLの取り組みと成果を見てみましょう。

II. 要点

並列に実行できるかどうかは、複数のトランザクション間でロックの競合があるかどうかによって決まります。これが鍵となります。 次の並列レプリケーションの原則は、ロックの競合を回避する方法を確認することです。

MySQL 5.6 スキーマベースの並列レプリケーション

slave-parallel-type=DATABASE (異なるデータベース内のトランザクション、ロック競合なし)

前述のように、並列レプリケーションの目的は、スレーブを可能な限りマルチスレッドで実行することです。もちろん、ライブラリレベルに基づくマルチスレッド化も方法の1つです（異なるライブラリでのトランザクション、ロックの競合なし）

まずメリットについてお話ししましょう。実装が比較的簡単で、ユーザーにとって使いやすいです。次にデメリットについてお話ししましょう。ライブラリに基づいているため、並列処理の粒度が非常に粗いです。現在、多くの企業のアーキテクチャは 1 つのライブラリと 1 つのインスタンスです。このようなアーキテクチャでは、5.6 並列レプリケーションは無力です。もちろん、マスターとスレーブのトランザクションの順序もあり、これも5.6では大きな問題です。

さっそく写真をいくつか紹介します

4. MySQL 5.7 グループコミットに基づく並列レプリケーション

slave-parallel-type=LOGICAL_CLOCK : コミット ペアレント ベース モード (同じグループ内のトランザクション [同じ最後のコミット]、ロックの競合なし。同じグループ内では競合があってはならず、競合がある場合は同じグループにすることはできません)
slave-parallel-type=LOGICAL_CLOCK : ロックベースモード (トランザクションが同じグループにない場合でも、トランザクション間にロック競合 [準備フェーズ] がない限り、同時実行が可能です。同じグループにない場合、N 個のトランザクションの準備フェーズが重複できる限り、ロック競合は発生しません)

グループコミットについては以前の記事で詳しく説明しているので、ここでは説明しません。 MySQL5.7ではグループをコミットするときに、各グループのトランザクションもマークします。これはMTSの利便性のためだと思います。

まずはバイナリログを見てみましょう

最終コミット=0 シーケンス番号=1
最終コミット=1 シーケンス番号=2
最終コミット=2 シーケンス番号=3
最終コミット=3 シーケンス番号=4
最終コミット=4 シーケンス番号=5
最終コミット=4 シーケンス番号=6
最終コミット=4 シーケンス番号=7
最終コミット=6 シーケンス番号=8
最終コミット=6 シーケンス番号=9
最終コミット=9 シーケンス番号=10

4.1 コミット親ベースモード

4.2 ロックベースモード

5. MySQL 8.0 書き込みセットに基づく並列レプリケーション

主キーに基づく競合検出 (binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION、変更された行の主キーまたは空でない一意のキーが競合しない場合は並列化が可能です)
5.7.22は書き込みセットメカニズムもサポートしています

トランザクションの依存関係: binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION

COMMIT_ORDERE: グループベースのコミットを続行する
WRITESET: 書き込みセットに基づいてトランザクションの依存関係を決定する
WRITESET_SESSION: 書き込みセットに基づきますが、同じセッション内のトランザクションは同じlast_committedを持ちません。

トランザクション検出アルゴリズム: transaction_write_set_extraction = OFF| XXHASH64 | MURMUR32

MySQL には、送信されたトランザクションの HASH 値を格納する変数があります。送信されたすべてのトランザクションによって変更された主キー (または一意のキー) の値は、ハッシュ化後にその変数のセットと比較され、変更された行がそれと競合するかどうかが判断され、依存関係が決定されます。

ここで言及した変数のサイズは、binlog_transaction_dependency_history_size で設定できます。

この粒度は行レベルです。このとき、並列粒度はより細かくなり、並列速度はより速くなります。場合によっては、スレーブの並列性がマスターの並列性を上回ると言っても過言ではありません（マスターはシングルスレッドの書き込みで、スレーブも並列再生できます）

6. スレーブの並列レプリケーションとマスターのトランザクション実行順序を一致させるにはどうすればよいですか?

5.7.19以降では、 slave_preserve_commit_order = 1設定できます。

公式説明:

マルチスレッド スレーブの場合、この変数を有効にすると、トランザクションがスレーブのリレー ログに表示されるのと同じ順序でスレーブ上で外部化されることが保証されます。
この変数を設定しても、マルチスレッドが有効になっていないスレーブには影響はありません。
この変数を変更する前に、すべてのレプリケーション スレッド (複数のレプリケーション チャネルを使用している場合はすべてのレプリケーション チャネル) を停止する必要があります。
--log-bin および --log-slave-updates はスレーブ上で有効にする必要があります。
さらに、--slave-parallel-type を LOGICAL_CLOCK に設定する必要があります。
マルチスレッド スレーブが起動されると、トランザクションは並列実行を開始できます。
slave_preserve_commit_order を有効にすると、実行中のスレッドは、以前のすべてのトランザクションがコミットされるまで待機してからコミットします。
スレーブ スレッドは、他のワーカーがトランザクションをコミットするのを待機している間、そのステータスを「先行するトランザクションのコミットを待機中」として報告します。

一般的な実装原則は、実行フェーズは並列で実行でき、バイナリログのフラッシュは順番に実行されるというものです。 エンジン層がコミットすると、binlog_order_commitに従ってキューの順序で完了します。

つまり、このパラメータが設定されている場合、スレーブはマスターと同様に並列化されます。

要約する

上記はこの記事の全内容です。この記事の内容が皆さんの勉強や仕事に一定の参考学習価値を持つことを願っています。ご質問があれば、メッセージを残してコミュニケーションしてください。123WORDPRESS.COM を応援していただきありがとうございます。