MySQL Replication--事务组提交和多线程复制

事务组提交和多线程复制

在MySQL 5.7版本引入基于LOGICAL_CLOCK的多线程复制，依赖于BINLOG事件中的last_committed属性，该last_committed属性是否与事务组提交特性有关呢？

测试环境：

MySQL 版本： MySQL 5.7.19
MySQL 参数：
binlog_format=STATEMENT
binlog_group_commit_sync_delay=0
binlog_group_commit_sync_no_delay_count=0

虽然参数binlog_group_commit_sync_no_delay_count=0，但不代表关闭事务组提交特性。

测试示例：

1、在测试库上依次执行事务1-->事务2-->事务3，但均不提交，三个事务中的SQL不存在冲突，都可以正常执行。

## 事务1
BEGIN;
UPDATE tb002 
SET c2=11 
WHERE c1=1;

## 事务2
BEGIN;
UPDATE tb002 
SET c2=22 
WHERE c1=2;

## 事务3
BEGIN;
UPDATE tb002 
SET c2=32 
WHERE c1=3;

2、按照事务3-->事务1-->事务2的顺序提交事务。

3、解析binlog文件

/export/servers/mysql/bin/mysqlbinlog -vv /export/data/mysql/data/mysql-bin.000013

# at 21216
#190701 23:07:55 server id 1614520  end_log_pos 21281 CRC32 0xe0b32069     GTID    last_committed=69    sequence_number=70    rbr_only=no
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:133'/*!*/;
# at 21281
#190701 23:07:55 server id 1614520  end_log_pos 21362 CRC32 0xf970363b     Query    thread_id=13946    exec_time=0    error_code=0
SET TIMESTAMP=1561993675/*!*/;
BEGIN
/*!*/;
# at 21362
# at 21394
#190701 23:07:55 server id 1614520  end_log_pos 21394 CRC32 0x898abcdd     Intvar
SET INSERT_ID=3/*!*/;
#190701 23:07:55 server id 1614520  end_log_pos 21513 CRC32 0xd4f17cf4     Query    thread_id=13946    exec_time=0    error_code=0
SET TIMESTAMP=1561993675/*!*/;
insert into tb002(c2,c3) select 1430,'1430'
/*!*/;
# at 21513
#190701 23:07:55 server id 1614520  end_log_pos 21544 CRC32 0xd04864cb     Xid = 42219
COMMIT/*!*/;
# at 21544
#190708 15:58:58 server id 1614520  end_log_pos 21609 CRC32 0x6dce809a     GTID    last_committed=70    sequence_number=71    rbr_only=no
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:134'/*!*/;
# at 21609
#190708 15:57:59 server id 1614520  end_log_pos 21690 CRC32 0x58c7f42e     Query    thread_id=13947    exec_time=0    error_code=0
SET TIMESTAMP=1562572679/*!*/;
BEGIN
/*!*/;
# at 21690
#190708 15:57:59 server id 1614520  end_log_pos 21798 CRC32 0x2c04a7a1     Query    thread_id=13947    exec_time=0    error_code=0
SET TIMESTAMP=1562572679/*!*/;
UPDATE tb002 SET c2=1 WHERE c1=1
/*!*/;
# at 21798
#190708 15:58:58 server id 1614520  end_log_pos 21829 CRC32 0xa1d16066     Xid = 42244
COMMIT/*!*/;
# at 21829
#190708 16:00:11 server id 1614520  end_log_pos 21894 CRC32 0xc3247c44     GTID    last_committed=71    sequence_number=72    rbr_only=no
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:135'/*!*/;
# at 21894
#190708 16:00:05 server id 1614520  end_log_pos 21975 CRC32 0x497a029d     Query    thread_id=13949    exec_time=0    error_code=0
SET TIMESTAMP=1562572805/*!*/;
BEGIN
/*!*/;
# at 21975
#190708 16:00:05 server id 1614520  end_log_pos 22084 CRC32 0x1ad87709     Query    thread_id=13949    exec_time=0    error_code=0
SET TIMESTAMP=1562572805/*!*/;
UPDATE tb002 SET c2=32 WHERE c1=3
/*!*/;
# at 22084
#190708 16:00:11 server id 1614520  end_log_pos 22115 CRC32 0x5dfd7cf0     Xid = 42266
COMMIT/*!*/;
# at 22115
#190708 16:00:18 server id 1614520  end_log_pos 22180 CRC32 0x6291b7e7     GTID    last_committed=71    sequence_number=73    rbr_only=no
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:136'/*!*/;
# at 22180
#190708 15:59:45 server id 1614520  end_log_pos 22261 CRC32 0x51f1f46a     Query    thread_id=13947    exec_time=0    error_code=0
SET TIMESTAMP=1562572785/*!*/;
BEGIN
/*!*/;
# at 22261
#190708 15:59:45 server id 1614520  end_log_pos 22370 CRC32 0x85218310     Query    thread_id=13947    exec_time=0    error_code=0
SET TIMESTAMP=1562572785/*!*/;
UPDATE tb002 SET c2=11 WHERE c1=1
/*!*/;
# at 22370
#190708 16:00:18 server id 1614520  end_log_pos 22401 CRC32 0x895b75bf     Xid = 42260
COMMIT/*!*/;
# at 22401
#190708 16:00:23 server id 1614520  end_log_pos 22466 CRC32 0x4bbabfe8     GTID    last_committed=71    sequence_number=74    rbr_only=no
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:137'/*!*/;
# at 22466
#190708 15:59:55 server id 1614520  end_log_pos 22547 CRC32 0x00e0c7c6     Query    thread_id=13948    exec_time=0    error_code=0
SET TIMESTAMP=1562572795/*!*/;
BEGIN
/*!*/;
# at 22547
#190708 15:59:55 server id 1614520  end_log_pos 22656 CRC32 0xeb83bb3c     Query    thread_id=13948    exec_time=0    error_code=0
SET TIMESTAMP=1562572795/*!*/;
UPDATE tb002 SET c2=22 WHERE c1=2
/*!*/;
# at 22656
#190708 16:00:23 server id 1614520  end_log_pos 22687 CRC32 0x8240be81     Xid = 42263
COMMIT/*!*/;

通过上面的BINLOG可以发现，三个事务在三个不同时间点提交且提交时间相差数秒，不可能被放到同一个事务组中进行提交，三个事务提交时的系统last_committed为变化为：

但三个事务的BINLOG中的last_committed相同，都是这三个事务开始前的最后一个事务的sequence_number，因此可以证明BINLOG中的last_committed值取决于事务中最后一条语句执行完成的时间点，而与事务提交时间点无关。

当上面三个事务的BINLOG事件传递到从库执行时，从库SQL线程通过对比last_committed的值确认这三个事务的BINLOG事件可以并发执行，因此可以交给不同的线程进行处理。

总结：

在MySQL 5.7早期版本中，MySQL多线程复制依赖于MySQL事务组提交特性，但在后续版本中进行优化，在BINLOG中记录事务中最后一条语句执行完成时的系统last_committed，由于该语句已经完成(未被阻塞)，因此拥有相同系统last_committed值的事务不会存在冲突，即使这些事务在后续不同时间点进行提交，但在从库上仍可以并行执行。