MariaDB & Percona XtraDB Group Commit实现简要分析

4月 18th, 2012

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:

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

  • BinlogMySQL起着TC(Transaction Coordinator)功能(Binlog只是TC的一种方案,另一种是Mmap TC)
  • TCcrash恢复时作为控制中心,决定各引擎参与事务的提交与回滚(WL#164之前,binlog只能与innodb-flush-log-at-trx-commit = 1设置同时使用,binlog中的事务一定commit;不存在与binlog中的事务一定rollback;不存在re-play binlog的操作)
  • MySQLTC做了所谓“middle engine”XA优化(在参与XA事务的所有参与者中,有且仅有一个参与者可以将【preparecommit】组合简化为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。将一次事务提交需要的3fsync,降低为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之后,binlogInnoDB redo log之间的关系,存在以下几种组合:

  • Binlogcommit log同时存在 ——no operation in crash recovery
  • Binlogprepare 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日志,如何恢复?
目前还没有任何评论.