这篇文章给大家介绍如何理解MySQL多线程复制，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
目前创新互联建站已为千余家的企业提供了网站建设、域名、雅安服务器托管、网站托管维护、企业网站设计、光山网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
Enhanced Multi-threaded Slaves
首先梳理下传统MySQL/MariaDB主备复制基本原理：
主从复制通过三个线程来完成，在master节点运行的binlog dump的线程，I/O线程和SQL线程运行在slave 节点
master节点的Binlog dump线程，当slave节点与master正常连接的时候，master把更新的binlog 内容推送到slave节点。
slave节点的I/O 线程 ，该线程通过读取master节点binlog日志名称以及偏移量信息将其拷贝到本地relay log日志文件。
slave节点的SQL线程，该线程读取relay log日志信息，将在master节点上提交的事务在本地回放，达到与主库数据保持一致的目的。
问题1：
Master节点的数据库实例并发跑多个线程同时提交事务，提交的事务按照逻辑的时间（数据库LSN号）顺序地写入binary log日志，,slave节点通过I/O线程写到本地的relay
log日志，但是slave节点只有SQL单线程来执行relay log中的日志信息重放主库提交得事务，造成主备数据库存在延迟（lag）
思考1：
那么为了减少主备数据同步延迟时间，由于备库只有单线程补偿数据的原因而造成延迟，那么能否使slave节点同时运行多个如SQL线程一样的功能来重放在主库执行的事务？答案当然是：可以！但是我们需要解决以下问题：
1、slave本地的relay
log记录的是master 的binary log日志信息，日志记录的信息按照事务的时间先后顺序记录，那么为了保证主备数据一致性，slave节点必须按照同样的顺序执行，如果顺序不一致容易造成主备库数据不一致的风险。
如：
在master节点提交T1和T2事务按照以下顺序
1. State0: x= 1, y= 1
2. T1: { x:= Read(y);
3.
x:= x+1;
4.
Write(x);
5.
Commit; }
6.
State1: x= 2, y= 1
7. T2: { y:= Read(x);
8.
y:=y+1;
9.
Write(y);
10.
Commit; }
11.
State2: x= 2, y= 3
slave节点执行T1和T2相反的顺序：
1. State0: x= 1, y= 1
2. T2: { y:= Read(x);
3.
y:= y+1;
4.
Write(y);
5.
Commit; }
6.
State1: x= 1, y= 2
7. T1: { x:= Read(y);
8.
x:=x+1;
9.
Write(x);
10.
Commit; }
11.
State2: x= 3, y= 2
MySQL 5.6改进：
MySQL
5.6版本引入并发复制（schema级别），基于schema级别的并发复制核心思想：“不同schema下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致”。可见MySQL5.6版本的并发复制，一个schema分配一个类似SQL线程的功能。
实现1：
slave节点开启并发复制（slave_parallel_workers＝3）如下图，当前的slave的SQL线程为Coordinator（协调器），执行relay
log日志的线程为worker(当前的SQL线程不仅起到协调器的作用，同时也可以重放relay log中主库提交的事务)
1. +-----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
2. | Id | User | Host | db | Command | Time | State
| Info |
3. +-----+-------------+-----------+------+---------+-------+--------------------------------------------------------+------------------+
4. | 1 | system
user | | NULL | Connect | 29923 | Slave has read all relay log; waiting for more updates | NULL |
5. | 2 | system
user | | NULL | Connect | 29923 | Waiting for an event
from Coordinator
| NULL
|
6. | 3 | system
user | | NULL | Connect | 29923 | Waiting for an event
from Coordinator
| NULL
|
7. | 4 | system
user | | NULL | Connect | 29923 | Waiting for an event
from Coordinator
| NULL
|
问题2:
MySQL
5.6基于schema级别的并发复制能够解决当业务数据的表放在不同的database库下，但是实际生产中往往大多数或者全部的业务数据表都放在同一个schema下，在这种场景即使slave_parallel_workers>0设置也无法并发执行relay
log中记录的主库提交数据。 高并发的情况下，由于slave无法并发执行同个schema下的业务数据表，依然会造成主备延迟的情况。
思考2：
那么如果slave同时可以用多线程的方式，同时执行一个schema下的所有业务数据表，将能大大提高slave节点执行ralay log中记录的主库提交事务达到与主库数据同步的目的，实现该功能我们需要解决什么问题？
实现2:
MySQL 5.7 引入Enhanced
Muti-threaded slaves,当slave配置slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’,可支持一个schema下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。但是要实现以上功能，需要在master机器标记binary log中的提交的事务哪些是可以并发执行，虽然MySQL
5.6已经引入了binary log group commit，但是没有将可以并发执行的事务标记出来。
我们用命令 mysqlbinlog -vvv mysqlbinlog.0000003 |
grep -i last_committed 在MySQL 5.7的master机器上可以看到last_committed 和sequence_number
1. #151223 15:11:28 server id 15102
end_log_pos 14623 CRC32 0x767a33fa GTID last_committed=18 sequence_number=26
2.
3. #151223 15:11:28 server id 15102
end_log_pos 15199 CRC32 0x7dd1bf05 GTID last_committed=26 sequence_number=27
4.
5. #151223 15:11:28 server id 15102
end_log_pos 15773 CRC32 0xb01dc76e GTID last_committed=26 sequence_number=28
6.
7. #151223 15:11:28 server id 15102
end_log_pos 16347 CRC32 0x7a8e0ee8 GTID last_committed=26 sequence_number=29
8.
9. #151223 15:11:28 server id 15102
end_log_pos 16921 CRC32 0x92516d17 GTID last_committed=26 sequence_number=30
10.
11. #151223 15:11:28 server id 15102
end_log_pos 17495 CRC32 0xeb14a51e GTID last_committed=26 sequence_number=31
12.
13. #151223 15:11:28 server id 15102
end_log_pos 18071 CRC32 0x750667d0 GTID last_committed=26 sequence_number=32
14.
15. #151223 15:11:28 server id 15102 end_log_pos
18645 CRC32 0xcaed6159 GTID last_committed=26 sequence_number=33
16.
17. #151223 15:11:28 server id 15102
end_log_pos 19219 CRC32 0x62408408 GTID last_committed=26 sequence_number=34
18.
19. #151223 15:11:28 server id 15102
end_log_pos 19793 CRC32 0x5cf46239 GTID last_committed=33 sequence_number=35
slave机器的relay log中 last_committed相同的事务（sequence_num不同）可以并发执行。从上面截取的信息可以看出last_committed=26的事务一共有8个：从sequence_number=27~24。假设当slave_parallel_workers=7时，Coordinator线程（SQL线程）分配这一组事务到worker中排队去执行。这里可以看出增加master库binary log group commit组中事务的数量可以提高slave机器并发处理事务的数量，MySQL5.7引入 binlog_group_commit_sync_delay和
binlog_group_commit_sync_no_delay_count参数即提高binary log组提交并发数量。MySQL等待binlog_group_commit_sync_delay毫秒的时间直到binlog_group_commit_sync_no_delay_count个事务数时，将进行一次组提交。
总结:
MySQL 5.7 GA版本推出的 Enhanced Multi-threaded Slaves功能，彻底解决了之前版本主备数据复制延迟的问题，开启该功能参数如下：
1. # slave机器
2. slave-parallel-type=LOGICAL_CLOCK
3. ＃slave-parallel-type=DATABASE #兼容MySQL 5.6基于schema级别的并发复制
4. slave-parallel-workers=16 ＃开启多线程复制
5. master_info_repository=TABLE
6. relay_log_info_repository=TABLE
7. relay_log_recovery=ON
关于如何理解MySQL多线程复制就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
当前文章：如何理解MySQL多线程复制
浏览地址：
http://cdkjz.cn/article/igsopd.html
