MariaDB & Percona XtraDB Group Commit实现简要分析
Mysql/InnoDB一直有一个Bug,就是当开启binlog时无法进行group commit。究其原因,是为了保证InnoDB日志与mysqlbinlog日志的顺序一致性。
在prepare前需要获取mutex,直到commit完成之后释放,这也禁用了group commit的功能。
对于InnoDB group commit的分析,可参考系列文章:Mysql/InnoDB和Group Commit(1);Mysql/InnoDB和Group Commit(2)
对于MariaDB / PerconaXtraDB如何实现Group commit,可参考MariaDB网站的3篇WorkLog:
-
WL#132: Transaction coordinator plugin
Percona 5.5.19-rel24代码分析:
以下分析Group Commit的具体实现,基于Percona 5.5.19-rel24。
以下提到的功能,在WorkLog WL#116中都有提及。建议先看WL#116,然后有针对性的看下面的函数实现,绝对事半功倍。
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的事务负责余下操作;其余事务进入等待。
if (orig_queue != NULL)
entry->thd->wait_for_wakeup_ready();
else
trx_group_commit_leader(entry);
commit_ordered功能:
ha_innodb.cc::innobase_init ->innobase_hton->commit_ordered = innobase_commit_ordered
XA事务总流程:
handler.cc::ha_commit_trans()函数分析
for (Ha_trx_info *hi = ha_info; hi; hi = hi->next())
handlerton *ht = hi->ht();
// XA事务第一阶段,group fsync prepare日志
// 其中,binlog的prepare方法为空实现
err = ht->prepare();
need_commit_ordered |= (ht->commit_ordered != NULL);
// Binlog group commit,然后调用commit_ordered进行排序
cookie = tc_log->log_and_order();
// XA事务第二阶段,fsync commit日志
error = commit_one_phase_low();
TC_LOG_BINLOG::log_and_order()函数分析
binlog_commit_flush_stmt/trx_cache();
binlog_flush_cache();
write_transaction_to_binlog();
// 事务首先进入binlog group commit queue
// 第一个进入的事务进行binlog group commit
// 其余事务进入等待
write_transaction_to_binlog_events();
trx_group_commit_leader(); (entry->thd->wait_for_wakeup_ready())
…
// binlog完成fsync之后,调用此函数对事物进行排序
// 排序前,需要获取LOCK_commit_orderedmutex
run_commit_ordered();
for ( … )
ht->commit_ordered();
// InnoDB提供了此函数,实现排序功能
innobase_commit_ordered();
Log.cc::MYSQL_BIN_LOG::trx_group_commit_leader()函数分析
// 获取当前queue,并且重新开启一个queue
// 本queue中的binlog,都由当前事务group commit
// 新queue中的binlog,由新queue中的第一个事务等待LOCK_logmutex
mysql_mutex_lock(&LOCK_log);
mysql_mutex_lock(&LOCK_group_commit_queue);
current = group_commit_queue;
group_commit_queue = NULL;
mysql_mutex_unlock(&LOCK_group_commit_queue);
// 写binlog,最后执行一次fsync操作
for ( … )
write_transaction();
flush_and_sync();
// 获取commit_orderedmutex,然后才能释放LOCK_logmutex
// 保证下一个queue,不会在当前queue之前调用commit_ordered
mysql_mutex_lock(&LOCK_commit_ordered);
mysql_mutex_unlock(&LOCK_log);
// 按照prepare的顺序,调用引擎提供的commit_ordered方法
// 由于是按序逐个执行commit_ordered方法,因此能够保证事务
// commit的顺序与binlog commit的顺序是完全一致的
// 在commit_ordered方法调用完成之后,才能唤醒对应的线程
// 事务线程被唤醒之后,才能够进入2PC的第二阶段
// 返回handler.cc::ha_commit_trans()函数,执行commit_one_phase_low
current = queue;
while (current != NULL)
run_commit_ordered(current->thd, current->all);
if (ht->commit_ordered)
ht->commit_ordered(ht, thd, all);
current->thd->signal_wakeup_ready();
current = next;
// 最后释放commit ordered mutex
mysql_mutex_unlock(&LOCK_commit_ordered);
ha_innodb.cc::innobase_commit_ordered ->innobase_commit_ordered_low函数分析
// 获取事务对应的binlog日志的位置
mysql_bin_log_commit_pos();
// 设置当前事务标识为flush log later,写commit日志,但是不flush
trx->flush_log_later = TRUE;
innobase_commit_low(trx);
trx->flush_log_later = FALSE;
在函数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日志,如何恢复?