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

事务组提交和多线程复制

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

测试环境：

MySQL 版本： MySQL 5.7.19MySQL 参数：

binlog_format=STATEMENT

binlog_group_commit_sync_delay=0binlog_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=11WHERE c1=1;

## 事务2

BEGIN;

UPDATE tb002

SET c2=22WHERE c1=2;

## 事务3

BEGIN;

UPDATE tb002

SET c2=32WHERE c1=3;

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

3、解析binlog文件

/export/servers/mysql/bin/mysqlbinlog -vv /export/data/mysql/data/mysql-bin.000013# at21216#190701 23:07:55 server id 1614520 end_log_pos 21281 CRC32 0xe0b32069 GTID last_committed=69 sequence_number=70 rbr_only=noSET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:133'/*!*/;

# at21281#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

/*!*/;

# at21362# at21394#190701 23:07:55 server id 1614520 end_log_pos 21394 CRC32 0x898abcddIntvarSET 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'

/*!*/;

# at21513#190701 23:07:55 server id 1614520 end_log_pos 21544 CRC32 0xd04864cb Xid = 42219

COMMIT/*!*/;

# at21544#190708 15:58:58 server id 1614520 end_log_pos 21609 CRC32 0x6dce809a GTID last_committed=70 sequence_number=71 rbr_only=noSET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:134'/*!*/;

# at21609#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

/*!*/;

# at21690#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

/*!*/;

# at21798#190708 15:58:58 server id 1614520 end_log_pos 21829 CRC32 0xa1d16066 Xid = 42244

COMMIT/*!*/;

# at21829#190708 16:00:11 server id 1614520 end_log_pos 21894 CRC32 0xc3247c44 GTID last_committed=71 sequence_number=72 rbr_only=noSET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:135'/*!*/;

# at21894#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

/*!*/;

# at21975#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

/*!*/;

# at22084#190708 16:00:11 server id 1614520 end_log_pos 22115 CRC32 0x5dfd7cf0 Xid = 42266

COMMIT/*!*/;

# at22115#190708 16:00:18server id 1614520 end_log_pos 22180 CRC32 0x6291b7e7 GTID last_committed=71 sequence_number=73 rbr_only=noSET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:136'/*!*/;

# at22180#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

/*!*/;

# at22261#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

/*!*/;

# at22370#190708 16:00:18 server id 1614520 end_log_pos 22401 CRC32 0x895b75bf Xid = 42260

COMMIT/*!*/;

# at22401#190708 16:00:23 server id 1614520 end_log_pos 22466 CRC32 0x4bbabfe8 GTID last_committed=71 sequence_number=74 rbr_only=noSET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:137'/*!*/;

# at22466#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

/*!*/;

# at22547#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

/*!*/;

# at22656#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值的事务不会存在冲突，即使这些事务在后续不同时间点进行提交，但在从库上仍可以并行执行。