Problems with Multiple XA Storage Engines in MySQL 5.6
While integrating TokuDB into MySQL 5.6, we found that MySQL 5.6 does not support more than one XA storage engine. For example, there is an assert in the ha_recover function that fires when the total number of XA storage engines is greater than one. After disabling this assert, we found lots of bugs in the MySQL 5.6 implementation of the TC_LOG_MMAP class, which is used when running with the binlog turned off.
There are two alternatives that we know of to fix this problem in MySQL 5.6:
- First, we could merge code from MariaDB 5.5 into MySQL 5.6. The advantage of this approach is that we have been running this code with TokuDB in MariaDB 5.5 for a long time, so we have confidence in its correctness.
- Second, we found that MySQL 5.7.2 has made changes to allow multiple XA storage engines. This is great news for TokuDB since we have one less MySQL patch to worry about. Our simple scan of the MySQL 5.7 source showed only one XA storage engine – InnoDB. This brings up two important questions. (1) What are the other XA storage engines in MySQL 5.7? and (2) How did this feature get tested?
Comment (1)
Regarding the MySQL 5.7 fix, the questions are answered in the commit message for the fix:
revno: 5201.2.1
committer: Dmitry Shulga
branch nick: mysql-trunk-bug11755370
timestamp: Fri 2013-03-01 19:02:41 +0600
message:
This patch fixes bug#11755370 – CRASH ON STARTUP WHEN XA SUPPORT FUNCTIONS
ACTIVATED BY A SECOND ENGINE.
…
MTR test isn’t added since there isn’t currently any other engine with
XA feature enabled aside from INNODB. I tested my patch using the fake second
engine with XA feature enabled that I created from ha_example.cc. I think
it won’t be correct to modify ha_example.cc just for the sake of patch test
coverage. Nevertheless I added unittest that runs 10 threads and calls
TC_LOG_MMAP::commit for distributed transactions. Such test should crash
the server without changes included in this patch. Also another two new unit
tests were added to test TC_LOG_MMAP behavior in situations when its
pages are close to be fully filled are fully filled.