探究MariaDB与percona xtradb数据库中的group commit
MySQL数据库InnoDB存储引擎一直有一个Bug，就是当开启binlog时，无法进行group commit。究其原因，是为了保证InnoDB存储引擎的事务日志与mysqlbinlog日志的顺序一致性。
在prepare前需要获取mutex，直到commit完成之后释放，这也禁用了group commit的功能。
Percona 5.5.19-rel24代码分析：
以下分析Group Commit的具体实现，基于Percona 5.5.19-rel24。
prepare_ordered功能：
|
Log.cc::MYSQL_BIN_LOG::write_transaction_to_binlog_events(group_commit_entry *entry) mysql_mutex_tLOCK_group_commit_queue; |
XA事务总流程：
在函数ha_innodb.cc::innobase_commit_ordered执行完成之后，逐层返回到handler.cc::ha_commit_trans()函数，执行2PC的第二阶段，commit_one_phase_low()，对Commit日志进行group
commit。
WL#132
二进制日志Binlog在MySQL数据库中起着TC(Transaction
Coordinator)功能二进制日志(Binlog只是TC的一种方案，另一种是Mmap TC);
TC在crash恢复时作为控制中心，决定各引擎参与事务的提交与回滚(在WL#164之前，binlog只能与innodb-flush-log-at-trx-commit
=
1设置同时使用，二进制日志binlog中的事务一定commit;不存在与binlog中的事务一定rollback;不存在re-play
binlog的操作);
MySQL数据库为TC做了所谓“middle
engine”XA优化(在参与XA事务的所有参与者中，有且仅有一个参与者可以将【prepare，commit】组合简化为commit即可，但是前提是此参与者的commit要在其他参与者完成prepare，未进行commit操作时进行，middle
engine)，Binlog不需要prepare阶段，其他引擎prepare之后直接写binlog即可;
二进制日志Binlog新增log_and_order方法，控制事务提交顺序;目前，InnoDB存储引擎实现了commit_ordered方法，未实现prepare_ordered方法。
WL#164
在Group
Commit的基础上，MariaDB数据库再接再厉，推出WL#164。将一次事务提交需要的3次fsync，降低为1次- binlog
fsync。用户可以在将参数innodb-flush-log-at-trx-commit设置为{0,2}时，达到与该参数为1时同样的可靠性，不会丢失已提交更新。实现方案也较为简洁，在原有XA
recover的基础上，新增了一个处理【二进制日志binlog存在，但是InnoDB prepare
log不存在】的情况，此时需要根据binlog重做(re-play)一遍即可(类似于slave根据binlog恢复的情形)。
在WL#164之后，binlog与InnoDB redo log之间的关系，存在以下几种组合：
Binlog与commit log同时存在 ——》no operation in crash recovery
Binlog与prepare log同时存在 ——》commit
Binlog存在，prepare log不存在 ——》re-play binlog
Binlog不存在，prepare log存在 ——》rollback
MySQL数据库外部XA事务支持，语法见上文。
经过测试，
在调用xa
prepare命令时，同样不写binlog，或者说是binlog的prepare为空。但是会写InnoDB存储引擎的prepare
log。
在调用xa commit命令时，会写binlog，同时写InnoDB存储引擎的commit log。
问题？二进制日志binlog不写prepare日志，如何恢复？
