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;

　　事务由mutex保护，加入queue，第一个加入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日志，如何恢复？