MySQL レプリケーションで並列レプリケーションを実装する方法

従来のシングルスレッド レプリケーション手順

ご存知のとおり、MySQL バージョン 5.6 より前は、MySQL のスレーブ ノードには 2 つのスレッドがありました。マスター/スレーブ レプリケーション、それぞれ I/O スレッドと SQL スレッド。

• #I/O スレッドは、バイナリ ログからイベントを受信し、それをリレー ログに書き込む役割を果たします。

• SQL スレッドはリレー ログを読み取り、データベースで再生します。

上記の方法では遅延が発生する場合がありますが、マスター ノードとスレーブ ノードの間で遅延が発生する可能性がある状況はどのような場合ですか?

• 1 .メイン データベースは大規模なトランザクション (大規模なテーブル構造の変更など) を実行します。

• 2. メイン データベースに対する大規模な変更 (大規模な挿入、更新、削除操作など)。

• 3. ROW 同期モードでは、メイン データベース内の大きなテーブルの主キーは頻繁には更新されません。

• 4. データベース パラメータの設定が不合理で、スレーブ ノードのパフォーマンスにボトルネックがあります (例: スレーブ ノードのトランザクション ログ設定が小さすぎるため、頻繁にディスク フラッシュが発生します)。

• 5. ネットワーク環境が不安定で、ノード IO スレッドからのバイナリログの読み取りに遅延や再接続が発生します。

• 6. マスターとスレーブのハードウェア構成が異なり、スレーブノードのハードウェアリソース使用量が上限に達しています。 (例: マスターノードの SSD ディスク、スレーブノードの SAS ディスク)

上記の遅延の理由は大まかに分類できます。

• 1. ハードウェアの問題 (ディスク IO、ネットワーク IO など)

• 2. 構成の問題。

• #3. データベース設計の問題。

• 4. マスター データベースが大量に変更されるため、スレーブ ノードの SQL シングル スレッド処理ではタイムリーではありません。

要約

上記の理由を分析した結果、マスター/スレーブ遅延を削減するには、ハードウェア条件を改善することに加えて、次のことがわかります。 DBA はデータベースの設計や構成の問題にも注意を払う必要があります。最後に、スレーブ ノードの同時処理能力を向上させる必要があります。シングル スレッドの再生からマルチスレッドの並列再生に変更する方が良い方法です。重要な点は、マルチスレッド回復を前提としたデータ競合と障害回復場所をどのように解決するかです。クリックして質問を確認します。

MySQL5.6 ライブラリ レベルに基づく並列レプリケーション

インスタンス内に複数のデータベースがある場合、複数のスレッドを開始でき、各スレッドが 1 つのデータベースに対応します。 。このモードでは、スレーブ ノードは複数のスレッドを開始します。スレッドは、

Coordinator と WorkThread の 2 つのカテゴリに分類されます。

• スレッド分業実行ロジック

コーディネータースレッドは、トランザクションが実行できるかどうかを決定する責任があります。並列実行できる場合は、トランザクションを WorkThread スレッドに振り分けて実行します DDL など、実行できないと判断した場合は、クロスライブラリ操作などは、すべてのワーカースレッドが実行されるまで待機し、その後、Coordinatorによって実行されます。

#主要な構成情報

• slave-parallel-type=DATABASE

#提案の欠点

• #この並列レプリケーション モデルは、インスタンス内に複数の DB があり、DB トランザクションが比較的ビジーな場合にのみ高度な並列処理を実現します。ただし、日常のメンテナンスでは、1 つのインスタンスのトランザクション処理が DB に比較的集中します。ほとんどの遅延は、ホットスポット テーブルの存在に基づいて観察されます。テーブルベースの並列処理を提供することをお勧めします。

MySQL5.7 グループ送信に基づく並列レプリケーション

グループ送信手順

簡単に言うと、double 1 設定の下で、トランザクション後につまり、ディスク ブラッシングの動作を変更し、複数のトランザクションをトランザクションのグループにマージし、統合されたディスク ブラッシングを実行することで、ディスク IO の負荷を軽減します。詳細については、

老叶茶馆

グループ投稿ツイートの手順

https://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg

を参照してください。 #一グループトランザクションを同時に投入するということは、グループ内のトランザクションに競合がないことを意味するため、グループ内のトランザクションをスレーブノード上で同時に実行することができます。同じグループなので、binlog に 2 つの新しいものが表示されます。 パラメーター情報 last_committed および

sequence_number

トランザクションがグループに属しているかどうかを確認するにはどうすればよいですか?

• バイナリログを解析すると、さらに 2 つのパラメータ情報、

  last_committed
と

sequence_number

があることがわかります。そのうち

last_committed が重複しています。

sequence_number

# この値は、トランザクション送信のシーケンス番号を指し、単調増加します。

• last_committed

  # この値には 2 つの意味があります。1. 同じ値は、これらのトランザクションが同じグループにあることを意味します。2. この値は、以前のトランザクションも表します。一連のトランザクションの最大数。

• [root@mgr2 GreatSQL]# mysqlbinlog mysql-bin.0000002 | grep last_committed
  GTID last_committed=0 sequence_number=1
  GTID last_committed=0 sequence_number=2
  GTID last_committed=2 sequence_number=3
  GTID last_committed=2 sequence_number=4
  GTID last_committed=2 sequence_number=5
  GTID last_committed=2 sequence_number=6
  GTID last_committed=6 sequence_number=7
  GTID last_committed=6 sequence_number=8

  データベース構成

slave-parallel-type=LOGICAL_CLOCK

• ソリューションの欠陥

基于组提交的同步有个不足点，就是当主节点的事务繁忙度较低的时候，导致时间段内组提交fsync刷盘的事务量较少，于是导致从库回放的并行度并不高，甚至可能一组里面只有一个事务，这样从节点的多线程就基本用不到，可以通过设置下面两个参数，让主节点延迟提交。

• binlog_group_commit_sync_delay # 等待延迟提交的时间，binlog提交后等待一段时间再 fsync。让每个 group 的事务更多，人为提高并行度。

• binlog_group_commit_sync_no_delay_count # 待提交的最大事务数，如果等待时间没到，而事务数达到了，就立即 fsync。达到期望的并行度后立即提交，尽量缩小等待延迟。

MySQL8.0基于writeset的并行复制

writeset 基于事务结果冲突进行判断事务是否可以进行并行回放的方法，他由binlog-transaction-dependency-tracking参数进行控制，默认采用WRITESET方法。

关键参数查看

Command-Line Format	--binlog-transaction-dependency-tracking=value
System Variable	binlog_transaction_dependency_tracking
Scope	Global
Dynamic	Yes
SET_VAR Hint Applies	No
Type	Enumeration
Default Value	COMMIT_ORDER
Valid Values	COMMIT_ORDER WRITESET WRITESET_SESSION

参数配置项说明

• COMMIT_ORDER # 使用 5.7 Group commit 的方式决定事务依赖。

• WRITESET     # 使用写集合的方式决定事务依赖。

• WRITESET_SESSION # 使用写集合，但是同一个session中的事务不会有相同的last_committed。

writeset 是一个HASH类型的数组，里面记录着事务的更新信息，通过transaction_write_set_extraction判断当前事务更新的记录与历史事务更新的记录是否存在冲突，判断过后再采取对应处理方法。writeset储存的最大存储值由binlog-transaction-dependency-history-size控制。

需要注意的是，当设置成WRITESET或WRITESET_SESSION的时候，事务提交是无序状态的，可以通过设置 slave_preserve_commit_order=1 强制按顺序提交。

• binlog_transaction_dependency_history_size

设定一个上限，限制在内存中缓存之前事务修改的行信息时所使用的行哈希数。一旦达到这个哈希数，就会清除历史记录。

Command-Line Format	--binlog-transaction-dependency-history-size=#
System Variable	binlog_transaction_dependency_history_size
Scope	Global
Dynamic	Yes
SET_VAR Hint Applies	No
Type	Integer
Default Value	25000
Minimum Value	1
Minimum Value	1000000

• transaction_write_set_extraction

该模式支持三种算法，默认采用XXHASH64，当从节点配置writeset复制的时候，该配置不能配置为OFF。在MySQL 8.0.26中，该参数已被标记为已弃用，将来将被删除。

Command-Line Format	--transaction-write-set-extraction[=value]
Deprecated	8.0.26
System Variable	binlog_transaction_dependency_history_size
Scope	Global, Session
Dynamic	Yes
SET_VAR Hint Applies	No
Type	Enumeration
Default Value	XXHASH64
Valid Values	OFF MURMUR32 XXHASH64

数据库配置

slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
binlog_transaction_dependency_tracking = WRITESET
slave_preserve_commit_order = 1

以上がMySQL レプリケーションで並列レプリケーションを実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。