作者:妈妈的话CPC-8_645 | 来源:互联网 | 2014-05-29 08:43
MySQL数据库InnoDB存储引擎一直有一个Bug,就是当开启binlog时,无法进行groupcommit。究其原因,是为了保证InnoDB存储引擎的事务日志与mysqlbinlog日志的顺序一致性。在prepare前需要获取mutex,直到commit完成之后释放,这也禁用了groupcommit的功能。P
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日志,如何恢复?