我的书签
添加书签
移除书签MySQL 5.7 外部XA Replication实现及缺陷分析
MySQL 5.7增强了分布式事务的支持，解决了之前客户端退出或者服务器关闭后prepared的事务回滚和服务器宕机后binlog丢失的情况。
为了解决之前的问题，MySQL5.7将外部XA在binlog中的记录分成了两部分，使用两个GTID来记录。执行prepare的时候就记录一次binlog，执行commit/rollback再记录一次。由于XA是分成两部分记录，那么XA事务在binlog中就可能是交叉出现的。Slave端的SQL线程在apply的时候需要能够在这些不同事务间切换。
但MySQL XA Replication的实现只考虑了Innodb一种事务引擎的情况，当添加其他事务引擎的时候，原本的一些代码逻辑就会有问题。同时MySQL源码中也存在宕机导致主备不一致的缺陷。
MySQL 5.7 外部XA Replication源码剖析
Master写入
当执行 XA START ‘xid’后，内部xa_state进入XA_ACTIVE状态。
1. bool Sql_cmd_xa_start::trans_xa_start(THD *thd)
2. {
3. xid_state->set_state(XID_STATE::XA_ACTIVE);
第一次记录DML操作的时候，通过下面代码可以看到，对普通事务在binlog的cache中第一个event记录’BEGIN’,如果是xa_state处于XA_ACTIVE状态就记录’XA START xid’，xid为序列化后的。
1. static int binlog_start_trans_and_stmt(THD *thd, Log_event *start_event)
2. {
3. if (cache_data->is_binlog_empty())
4. {
5. if (is_transactional && xs->has_state(XID_STATE::XA_ACTIVE))
6. {
7. /*
8. XA-prepare logging case.
9. */
10. qlen= sprintf(xa_start, "XA START %s", xs->get_xid()->serialize(buf));
11. query= xa_start;
12. }
13. else
14. {
15. /*
16. Regular transaction case.
17. */
18. query= begin;
19. }
21. Query_log_event qinfo(thd, query, qlen,
22. is_transactional, false, true, 0, true);
23. if (cache_data->write_event(thd, &qinfo))
24. DBUG_RETURN(1);
XA END xid的执行会将xa_state设置为XA_IDLE。
1. bool Sql_cmd_xa_end::trans_xa_end(THD *thd)
2. {
3. xid_state->set_state(XID_STATE::XA_IDLE);
当XA PREPARE xid执行的时候，binlog_prepare会通过检查thd的xa_state是否处于XA_IDLE状态来决定是否记录binlog。如果在对应状态，就会调用MYSQL_BINLOG的commit函数，记录’XA PREPARE xid’，将之前cache的binlog写入到文件。
1. static int binlog_prepare(handlerton *hton, THD *thd, bool all)
2. {
3. DBUG_RETURN(all && is_loggable_xa_prepare(thd) ?
4. mysql_bin_log.commit(thd, true) : 0);
7. inline bool is_loggable_xa_prepare(THD *thd)
8. {
9. return DBUG_EVALUATE_IF("simulate_commit_failure",
10. false,
11. thd->get_transaction()->xid_state()->
12. has_state(XID_STATE::XA_IDLE));
14. TC_LOG::enum_result MYSQL_BIN_LOG::commit(THD *thd, bool all)
15. {
16. if (is_loggable_xa_prepare(thd))
17. {
18. XID_STATE *xs= thd->get_transaction()->xid_state();
19. XA_prepare_log_event end_evt(thd, xs->get_xid(), one_phase);
20. err= cache_mngr->trx_cache.finalize(thd, &end_evt, xs)
21. }
当XA COMMIT/ROLLBACK xid执行时候，调用do_binlog_xa_commit_rollback记录’XA COMMIT/ROLLBACK xid’。
1. TC_LOG::enum_result MYSQL_BIN_LOG::commit(THD *thd, bool all)
2. {
3. if (thd->lex->sql_command == SQLCOM_XA_COMMIT)
4. do_binlog_xa_commit_rollback(thd, xs->get_xid(),
5. true)))
7. int MYSQL_BIN_LOG::rollback(THD *thd, bool all)
8. {
9. if (thd->lex->sql_command == SQLCOM_XA_ROLLBACK)
10. if ((error= do_binlog_xa_commit_rollback(thd, xs->get_xid(), false)))
由于XA PREPARE单独记录binlog，那么binlog中的events一个xa事务就可能是分隔开的。举个例子，session1中xid为’a’的分布式事务执行xa prepare后，session2中执行并提交了xid为’z’的事务，然后xid ‘a’才提交。我们可以看到binlog events中xid ‘z’的events在’a’的prepare和commit之间。
1. session1:
2. xa start 'a';
3. insert into t values(1);
4. xa end 'a';
5. xa prepare 'a';
7. session2:
8. xa start 'z';
9. insert into t values(2);
10. xa end 'z';
11. xa prepare 'z';
12. xa commit 'z';
14. session1:
15. xa commit 'a';
18. | mysql-bin.000008 | 250 | Gtid | 324 | 298 | SET @@SESSION.GTID_NEXT= 'uuid:9' |
19. | mysql-bin.000008 | 298 | Query | 324 | 385 | XA START X'61',X'',1 |
20. | mysql-bin.000008 | 385 | Table_map | 324 | 430 | table_id: 72 (test.t) |
21. | mysql-bin.000008 | 430 | Write_rows_v1 | 324 | 476 | table_id: 72 flags: STMT_END_F |
22. | mysql-bin.000008 | 476 | Query | 324 | 561 | XA END X'61',X'',1 |
23. | mysql-bin.000008 | 561 | XA_prepare | 324 | 598 | XA PREPARE X'61',X'',1 |
24. | mysql-bin.000008 | 598 | Gtid | 324 | 646 | SET @@SESSION.GTID_NEXT= 'uuid:10' |
25. | mysql-bin.000008 | 646 | Query | 324 | 733 | XA START X'7a',X'',1 |
26. | mysql-bin.000008 | 733 | Table_map | 324 | 778 | table_id: 72 (test.t) |
27. | mysql-bin.000008 | 778 | Write_rows_v1 | 324 | 824 | table_id: 72 flags: STMT_END_F |
28. | mysql-bin.000008 | 824 | Query | 324 | 909 | XA END X'7a',X'',1 |
29. | mysql-bin.000008 | 909 | XA_prepare | 324 | 946 | XA PREPARE X'7a',X'',1 |
30. | mysql-bin.000008 | 946 | Gtid | 324 | 994 | SET @@SESSION.GTID_NEXT= 'uuid:11' |
31. | mysql-bin.000008 | 994 | Query | 324 | 1082 | XA COMMIT X'7a',X'',1 |
32. | mysql-bin.000008 | 1082 | Gtid | 324 | 1130 | SET @@SESSION.GTID_NEXT= 'uuid:12' |
33. | mysql-bin.000008 | 1130 | Query | 324 | 1218 | XA COMMIT X'61',X'',1 |
Slave 重放
由于XA事务在binlog中是会交叉出现的，Slave的SQL线程如果按照原本普通事务的方式重放，那么就会出现SQL线程中还存在处于prepared状态的事务，就开始处理下一个事务了，锁状态、事务状态等会错乱。所以SQL线程需要能够支持这种情况下不同事务间的切换。
SQL线程要做到能够在执行XA事务时切换到不同事务，需要做到server层保留原有xid的Transaction_ctx信息，引擎层也保留原有xid的事务信息。
server层保留原有xid的Transaction_ctx信息是通过在prepare的时候将thd中xid的Transaction_ctx信息从transacion_cache中detach掉，创建新的保留了XA事务信息的Transaction_ctx放入transaction_cache中。
1. bool Sql_cmd_xa_prepare::execute(THD *thd)
2. !(st= applier_reset_xa_trans(thd)))
4. bool applier_reset_xa_trans(THD *thd)
5. transaction_cache_detach(trn_ctx);
7. bool transaction_cache_detach(Transaction_ctx *transaction)
8. res= create_and_insert_new_transaction(&xid, was_logged);
引擎层的实现并不是通过在prepare的时候创建新trx_t的来保存原有事务信息。而是在XA START的时候将原来thd中所有的engine ha_data单独保留起来，为XA事务创建新的。在XA PREPARE的时候，再将原来的reattach回来，将XA的从thd detach掉，解除XA和thd的关联。引擎层添加了新的接口replace_native_transaction_in_thd来支持上述操作。对于Slave的SQL线程，函数调用如下：
1. //engine 新添加的接口
2. struct handlerton
3. {
4. void (*replace_native_transaction_in_thd)(THD *thd, void *new_trx_arg, void **ptr_trx_arg);
6. //XA START函数调用
7. bool Sql_cmd_xa_start::execute(THD *thd)
8. {
9. thd->rpl_detach_engine_ha_data();
11. void THD::rpl_detach_engine_ha_data()
12. {
13. rli->detach_engine_ha_data(this);
15. //每个Storage engine都调用detach_native_trx
16. void Relay_log_info::detach_engine_ha_data(THD *thd)
17. {
18. plugin_foreach(thd, detach_native_trx,
19. MYSQL_STORAGE_ENGINE_PLUGIN, NULL);
21. my_bool detach_native_trx(THD *thd, plugin_ref plugin, void *unused)
22. {
23. if (hton->replace_native_transaction_in_thd)
24. hton->replace_native_transaction_in_thd(thd, NULL,
25. thd_ha_data_backup(thd, hton));
27. //XA PREPARE函数调用
28. bool Sql_cmd_xa_prepare::execute(THD *thd)
29. {
30. !(st= applier_reset_xa_trans(thd)))
32. bool applier_reset_xa_trans(THD *thd)
33. {
34. attach_native_trx(thd);
36. //对事务涉及到的引擎调用reattach_engine_ha_data_to_thd。
37. static void attach_native_trx(THD *thd)
38. {
39. if (ha_info)
40. {
41. for (; ha_info; ha_info= ha_info_next)
42. {
43. handlerton *hton= ha_info->ht();
44. reattach_engine_ha_data_to_thd(thd, hton);
45. ha_info_next= ha_info->next();
46. ha_info->reset();
47. }
48. }
50. inline void reattach_engine_ha_data_to_thd(THD *thd, const struct handlerton *hton)
51. {
52. if (hton->replace_native_transaction_in_thd)
53. hton->replace_native_transaction_in_thd(thd, *trx_backup, NULL);
当XA COMMIT/ROLLBACK执行的时候，如果当前thd中没有对应的xid，就会从transaction_cache中查找对应xid的state信息，然后调用各个引擎的commit_by_xid/rollback_by_xid接口提交/回滚XA事务。
1. bool Sql_cmd_xa_commit::trans_xa_commit(THD *thd)
2. {
3. if (!xid_state->has_same_xid(m_xid))
4. {
5. Transaction_ctx *transaction= transaction_cache_search(m_xid);
6. ha_commit_or_rollback_by_xid(thd, m_xid, !res);
8. static void ha_commit_or_rollback_by_xid(THD *thd, XID *xid, bool commit)
9. {
10. plugin_foreach(NULL, commit ? xacommit_handlerton : xarollback_handlerton,
11. MYSQL_STORAGE_ENGINE_PLUGIN, xid);
13. static my_bool xacommit_handlerton(THD *unused1, plugin_ref plugin, void *arg)
14. {
15. if (hton->state == SHOW_OPTION_YES && hton->recover)
16. hton->commit_by_xid(hton, (XID *)arg);
18. static my_bool xarollback_handlerton(THD *unused1, plugin_ref plugin, void *arg)
19. {
20. if (hton->state == SHOW_OPTION_YES && hton->recover)
21. hton->rollback_by_xid(hton, (XID *)arg);
由于XA COMMIT/XA ROLLBACK是单独作为一部分，这部分并没有原来XA事务涉及到库、表的信息，所以XA COMMIT在Slave端当slave-parallel-type为DATABASE时是无法并发执行的，在slave端强制设置mts_accessed_dbs为OVER_MAX_DBS_IN_EVENT_MTS使其串行执行。
1. bool Log_event::contains_partition_info(bool end_group_sets_max_dbs)
2. {
3. case binary_log::QUERY_EVENT:
4. {
5. Query_log_event *qev= static_cast<Query_log_event*>(this);
6. if ((ends_group() && end_group_sets_max_dbs) ||
7. (qev->is_query_prefix_match(STRING_WITH_LEN("XA COMMIT")) ||
8. qev->is_query_prefix_match(STRING_WITH_LEN("XA ROLLBACK"))))
9. {
10. res= true;
11. qev->mts_accessed_dbs= OVER_MAX_DBS_IN_EVENT_MTS;
12. }
MySQL5.7 外部XA Replication实现的缺陷分析
Prepare阶段可能导致主备不一致
MySQL中普通事务提交的时候，需要先在引擎中prepare，然后再写binlog，之后再做引擎commit。但在MySQL执行XA PREPARE的时候先写入了binlog，然后才做引擎的prepare。如果引擎在做prepare的时候失败或者服务器crash就会导致binlog和引擎不一致，主备进入不一致的状态。
在MySQL5.7中对模拟simulate_xa_failure_prepare的DEBUG情况做如下修改，使之模拟在Innodb引擎prepare的时候失败。
1. --- a/sql/handler.cc
2. +++ b/sql/handler.cc
3. @@ -1460,10 +1460,12 @@ int ha_prepare(THD *thd)
4. thd->status_var.ha_prepare_count++;
5. if (ht->prepare)
6. {
7. - DBUG_EXECUTE_IF("simulate_xa_failure_prepare", {
8. - ha_rollback_trans(thd, true);
9. - DBUG_RETURN(1);
10. - });
11. + if (ht->db_type == DB_TYPE_INNODB) {
12. + DBUG_EXECUTE_IF("simulate_xa_failure_prepare", {
13. + ha_rollback_trans(thd, true);
14. + DBUG_RETURN(1);
15. + });
16. + }
17. if (ht->prepare(ht, thd, true))
18. {
19. ha_rollback_trans(thd, true);
然后运行下面的case，可以看到Master上的XA失败后被回滚。但由于这个时候已经写入了binlog events，导致Slave端执行了XA事务，留下一个处于prepared状态的XA事务。
1. replication.test:
3. --disable_warnings
4. source include/master-slave.inc;
5. --enable_warnings
6. connection master;
7. CREATE TABLE ti (c1 INT) ENGINE=INNODB;
8. XA START 'x';
9. INSERT INTO ti VALUES(1);
10. XA END 'x';
11. SET @@session.debug = '+d,simulate_xa_failure_prepare';
12. --error ER_XA_RBROLLBACK
13. XA PREPARE 'x';
14. --echo #Master
15. XA RECOVER;
17. --sync_slave_with_master
18. connection slave;
19. --echo #Slave
20. XA RECOVER;
23. replication.result:
25. include/master-slave.inc
26. [connection master]
27. CREATE TABLE ti (c1 INT) ENGINE=INNODB;
28. XA START 'x';
29. INSERT INTO ti VALUES(1);
30. XA END 'x';
31. SET @@session.debug = '+d,simulate_xa_failure_prepare';
32. XA PREPARE 'x';
33. ERROR XA100: XA_RBROLLBACK: Transaction branch was rolled back
34. #Master
35. XA RECOVER;
36. formatID gtrid_length bqual_length data
37. #Slave
38. XA RECOVER;
39. formatID gtrid_length bqual_length data
40. 1 1 0 x
在MySQL5.7源码中，如果在binlog和InnoDB引擎都prepare之后是不是数据就安全了呢？我们在ha_prepare函数中while循环调用完所有引擎prepare函数之后添加如下DEBUG代码，可以控制在prepare调用结束后服务器crash掉。
1. --- a/sql/handler.cc
2. +++ b/sql/handler.cc
3. @@ -1479,6 +1479,7 @@ int ha_prepare(THD *thd)
4. }
5. ha_info= ha_info->next();
6. }
7. + DBUG_EXECUTE_IF("crash_after_xa_prepare", DBUG_SUICIDE(););
9. DBUG_ASSERT(thd->get_transaction()->xid_state()->
10. has_state(XID_STATE::XA_IDLE));
然后跑下面的testcase。可以看到即使所有引擎都prepare了，宕机重启后XA RECOVER还是还是没有能够找回之前prepare的事务。而且这个时候我们查看binlog文件可以看到binlog已经写成功，这也会导致主备不一致。很明显，应该是InnoDB引擎丢失了prepare的日志。那么是什么原因导致这个问题？感兴趣的同学可以查看int MYSQL_BIN_LOG::ordered_commit(THD *thd, bool all, bool skip_commit)和innobase中trx_prepare的代码，看process_flush_stage_queue和flush_logs和thd->durability_property的相关逻辑。这里不再展开详细叙述。
1. replication.test:
3. -- source include/have_log_bin.inc
4. CREATE TABLE ti (c1 INT) ENGINE=INNODB;
5. XA START 'x';
6. INSERT INTO ti VALUES(1);
7. XA END 'x';
8. SET @@session.debug = '+d,crash_after_xa_prepare';
9. --exec echo "wait" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
10. --error 2013
11. XA PREPARE 'x';
12. --source include/wait_until_disconnected.inc
13. --let $_expect_file_name= $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
14. --source include/start_mysqld.inc
15. XA RECOVER;
16. show binlog events in 'mysql.000001';
19. replication.result:
20. CREATE TABLE ti (c1 INT) ENGINE=INNODB;
21. XA START 'x';
22. INSERT INTO ti VALUES(1);
23. XA END 'x';
24. SET @@session.debug = '+d,crash_after_xa_prepare';
25. XA PREPARE 'x';
26. ERROR HY000: Lost connection to MySQL server during query
27. # restart
28. XA RECOVER;
29. formatID gtrid_length bqual_length data
30. show binlog events in 'mysql.000001';
31. Log_name Pos Event_type Server_id End_log_pos Info
32. mysql.000001 4 Format_desc 1 123 Server ver: 5.7.19org-debug-log, Binlog ver: 4
33. mysql.000001 123 Previous_gtids 1 154
34. mysql.000001 154 Anonymous_Gtid 1 219 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
35. mysql.000001 219 Query 1 331 use `test`; CREATE TABLE ti (c1 INT) ENGINE=INNODB
36. mysql.000001 331 Anonymous_Gtid 1 396 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
37. mysql.000001 396 Query 1 483 XA START X'78',X'',1
38. mysql.000001 483 Table_map 1 528 table_id: 222 (test.ti)
39. mysql.000001 528 Write_rows 1 568 table_id: 222 flags: STMT_END_F
40. mysql.000001 568 Query 1 653 XA END X'78',X'',1
41. mysql.000001 653 XA_prepare 1 690 XA PREPARE X'78',X'',1
上面两个问题的修复，都可以通过先执行事务引擎的prepare操作，再调用binlog的prepare来解决。
不支持server中使用多个事务引擎
在上面实现分析中可以看到Slave在执行XA START的时候，由于这个时候并不知道该XA事务涉及到哪些引擎，所以对所有Storage engine引擎都调用了detach_native_trx。但在XA PREPARE的时候，源码中只对XA涉及到的引擎调用了reattach_engine_ha_data_to_thd。对于引擎可插拔的MySQL来说，当server中不止一个事务引擎，这里就会存在有的引擎原thd中的trx被detach后没有被reattach。
我们可以拿支持tokudb的percona server做对应实验。对DEBUG编译的server，执行下面replication的testcase。该case对TokuDB做一个完整的XA事务后，再向Innodb写入。运行该case，slave端会产生assert_fail的错误。因为TokuDB执行XA事务时，将Innodb的ha_data放入backup，但由于Innodb没有参与该XA事务，所以并没有reattach，导致gdb可以看到assert_fail处InnoDB的ha_ptr_backup不为NULL，不符合预期。
1. replication.test
2. --disable_warnings
3. source include/master-slave.inc;
4. --enable_warnings
5. connection master;
6. create table tk(c1 int) engine=tokudb;
7. create table ti(c1 int) engine=innodb;
9. xa start 'x';
10. insert into tk values(1);
11. xa end 'x';
12. xa prepare 'x';
13. xa commit 'x';
15. insert into ti values(2);
17. __assert_fail
18. thd->ha_data[ht_arg->slot].ha_ptr_backup == __null || (thd->get_transaction()->xid_state()-> has_state(XID_STATE::XA_ACTIVE))"
20. (gdb) p thd->ha_data[ht_arg->slot].ha_ptr_backup
21. $1 = (void *) 0x2b11e0401070
修复问题，可以在需要reattach_engine_ha_data_to_thd的代码处，对所有storage engine再次调用该操作。
不支持新接口的事务引擎重放新XA事务会出错
对于不支持reattach_engine_ha_data_to_thd的事务引擎实际是不支持重放MySQL5.7新XA方式生成的binlog的，但在源码中并没有合适禁止操作。这就会导致slave在apply的时候数据错乱。
继续使用支持tokudb的percona server做实验。由于TokuDB并没有实现reattach_engine_ha_data_to_thd接口，Slave在重放XA事务的时候，在TokuDB引擎中实际就在原本关联thd的trx上操作，并没有生成新的trx。这就会导致数据等信息错乱，可以看到下面的例子。session1做了一个XA事务，插入数值1，prepare后并没有提交。随后另一个session插入数值2，但在slave同步后，数值2无法查询到。在session1提交了XA事务，写入TokuDB的数值1、2才在slave端查询到。
1. replication.test:
3. --disable_warnings
4. source include/master-slave.inc;
5. --enable_warnings
6. connection master;
7. --echo #Master
8. create table tk(c1 int) engine=tokudb;
9. xa start 'x';
10. insert into tk values(1);
11. xa end 'x';
12. xa prepare 'x';
13. connect(m, localhost, root, , test, $MASTER_MYPORT);
14. insert into tk values(2);
15. select * from tk;
17. --sync_slave_with_master
18. connection slave;
19. --echo #Slave
20. select * from tk;
22. connection master;
23. --echo #Master
24. xa commit 'x';
25. select * from tk;
27. --sync_slave_with_master
28. connection slave;
29. --echo #Slave
30. select * from tk;
32. connection master;
33. drop table tk;
37. replication.result:
39. include/master-slave.inc
40. [connection master]
41. #Master
42. create table tk(c1 int) engine=tokudb;
43. xa start 'x';
44. insert into tk values(1);
45. xa end 'x';
46. xa prepare 'x';
47. insert into tk values(2);
48. select * from tk;
49. c1
50. 2
51. #Slave
52. select * from tk;
53. c1
54. #Master
55. xa commit 'x';
56. select * from tk;
57. c1
58. 1
59. 2
60. #Slave
61. select * from tk;
62. c1
63. 1
64. 2
65. drop table tk;
修复该问题，需要对没有实现新接口的事务引擎在执行XA时候给与合适的禁止操作，同时需要支持新XA的事务引擎要实现reattach_engine_ha_data_to_thd接口。
