mysql复制那点事(2)-binlog组提交源码分析和实现

• 2019 年 10 月 3 日
• 筆記

mysql复制那点事(2)-binlog组提交源码分析和实现

[TOC]

0. 参考文献

本文主要介绍了mysql binlog组提交的原理和源码实现。感谢上述参考文献在本文形成的过程中提供的帮助。本文所介绍的内容如下：

1. mysql 两阶段提交实现的历史以及存在的问题
2. mysql binlog 组提交实现的原理

1. innodb和binlog的两阶段提交

众所周知，事务在innodb上提交的时候需要日志先行WAL(Write-Ahead-Log)。在binlog开启的情况下，为了保证binlog和存储引擎的一致性，会在事物提交的时候自动开启两阶段提交。对于单个事务，mysql实现的两阶段提交流程如图所示(参考文献 1 和 文献2 )：

1. 当事务进入PrePare阶段的时候，会在存储引擎层进行提交。生成undo log 和redo log 内存日志。
2. 之后生成binlog并调用sync落盘。
3. 在存储引擎层提交，通过 innodb_flush_log_at_trx_commit 参数的设置，使 undo 和 redo 永久写入磁盘。

在mysql启动恢复的阶段，会执行如下的操作：

1. 如果事务在prepare 阶段mysql异常退出，且binlog和innodb都没有提交。则在恢复阶段直接忽略这个事务不进行提交。
2. 如果事务在innodb commit的阶段异常，但是binlog已经写入了磁盘。则在恢复的时候，mysql会从binlog中提取信息，并把这个事务重做。

以上是mysql在开启binlog的情况下使用两阶段提交保证binlog和innodb层面都提交的流程。不过在并发的情况下，会存在一定的问题。如图所示，有3个事务T1，T2，T3 进入Prepare阶段：

下面来说明下图中T1，T2，T3提交的过程中都发生了什么：

1. T1 ，T2，T3依次写入binlog文件，并调用fsync一次性写入磁盘。
2. T2，T3 先行进入提交阶段执行commit。
3. 在T1提交之前，做了一次热备份（例如使用mysqlbackup，xtrabackup等工具）。此时因为T1没有提交，备份工具记录的当前binlog位置是指向的T3提交的时刻。
4. T1提交。

如果此时DBA使用上面第三点的备份数据，在其他机器上恢复备份并搭建主从复制，则T1事务会完美的被错过造成主从数据不一致。原因是因为备份开始同步binlog的位置是指向了T3提交的时刻（不会拉取T3提交时刻以前的binlog，因此T1提交的binlog不会被读取），而且因为T1在备份时刻没有提交，则在恢复备份的时候会被mysql回滚。

对于这个问题，在mysql5.6之前使用 prepare_commit_mutex 保证顺序。并且只有当上一个事务 commit 后释放锁，下个事务才可以进行 prepara 操作，并且在每个事务过程中 binlog 没有 fsync() 的调用。接下来介绍下，在使用prepare_commit_mutex 保证事务顺序提交的时候，为什么能够解决这个问题。

同样如上图所示，展示了3个事务T1，T2，T3顺序提交的时候的过程。如果DBA在T3写入binlog之后commit之前建立了一次备份，则如上所述T3 因为没有提交，在恢复备份的时候会被回滚。之后DBA在搭建同步的时候，根据备份时候备份工具（例如使用mysqlbackup，xtrabackup等工具）记录的参数从T2commit的时刻开始拉取binlog，则此时可以拉取到T3提交的事务并重放，因此保证了主从的一致性。在这里，可以看出如果使用了prepare_commit_mutex保证顺序提交，则会极大的影响mysql的并发性能。因此在mysql5.6开始提出了binlog组提交的改进。

2. 组提交原理

上文提到mysql5.6 之后对于binlog的提交做了改进。首先去掉了prepare_commit_mutex锁，并且把整个commit阶段分为3个部分：

1. FLUSH：在这个阶段leader事务把thd的缓存写到binlog文件的缓存中。
2. SYNC：在这个阶段leader事务调用fsync把缓存一次性落盘。
3. COMMIT ：在这个阶段，根据参数binlog_order_commits的设定，让事务依次提交或者各种提交(binlog中提交的顺序可能会和innodb中提交的顺序不同)

组提交的流程如图所示：

从上图中可以看出，每个阶段都会产生一个leader进程。当一个事务进程进入队列的时候，会有如下的2种情况：

1. 队列为空。
2. 队列中已有其他的事务。

在第一种情况下，当前事务称为leader进程，后续进来事务成为follower 并使用条件变量进入休眠。后续的工作会由leader进程代替follower进程完成。在第二种情况下，当前事务会成为followr进而休眠等到leader 完成剩余的工作。

3. 组提交实现

前文介绍了组提交的原理，本小节将介绍下组提交在mysql源码层面上的实现过程。本文去掉了代码中关于错误处理、同步和其他输出代码，保留了组提交主流程的相关代码。

3.1 order_commit

如上图所示，组提交的入口是order_commit 函数:

 9498 int MYSQL_BIN_LOG::ordered_commit(THD *thd, bool all, bool skip_commit)   9499 {    				... ...     9570   if (change_stage(thd, Stage_manager::FLUSH_STAGE, thd, NULL, &LOCK_log))   9571   {   9572     DBUG_PRINT("return", ("Thread ID: %u, commit_error: %d",   9573                           thd->thread_id(), thd->commit_error));   9574     DBUG_RETURN(finish_commit(thd));   9575   }            ... ...     9594   flush_error= process_flush_stage_queue(&total_bytes, &do_rotate,   9595                                                  &wait_queue);              ... ...     9646   /*   9647     Shall introduce a delay only if it is going to do sync   9648     in this ongoing SYNC stage. The "+1" used below in the   9649     if condition is to count the ongoing sync stage.   9650     When sync_binlog=0 (where we never do sync in BGC group),   9651     it is considered as a special case and delay will be executed   9652     for every group just like how it is done when sync_binlog= 1.   9653   */   9654   if (!flush_error && (sync_counter + 1 >= get_sync_period()))   9655     stage_manager.wait_count_or_timeout(opt_binlog_group_commit_sync_no_delay_count,   9656                                         opt_binlog_group_commit_sync_delay,   9657                                         Stage_manager::SYNC_STAGE);       				... ...     9639   if (change_stage(thd, Stage_manager::SYNC_STAGE, wait_queue, &LOCK_log, &LOCK_sync))   9640   {   9641     DBUG_PRINT("return", ("Thread ID: %u, commit_error: %d",   9642                           thd->thread_id(), thd->commit_error));   9643     DBUG_RETURN(finish_commit(thd));   9644   }              ... ...     9661   if (flush_error == 0 && total_bytes > 0)   9662   {   9663     DEBUG_SYNC(thd, "before_sync_binlog_file");   9664     std::pair<bool, bool> result= sync_binlog_file(false);   9665     sync_error= result.first;   9666   }   9667   				 ... ...     9702 commit_stage:   9703   if (opt_binlog_order_commits &&   9704       (sync_error == 0 || binlog_error_action != ABORT_SERVER))   9705   {   9706     if (change_stage(thd, Stage_manager::COMMIT_STAGE,   9707                      final_queue, leave_mutex_before_commit_stage,   9708                      &LOCK_commit))             ... ...     9736     process_commit_stage_queue(thd, commit_queue);   9737     mysql_mutex_unlock(&LOCK_commit);             ... ...     9759   /* Commit done so signal all waiting threads */   9760   stage_manager.signal_done(final_queue);           ... ...           }  

如源码所示，在commit阶段会调用change_stage函数3次，分别传入不同的参数FLUSH_STAGE、SYNC_STAGE和COMMIT_STAGE。change_stage主要用于事务加入队列。在代码中有一个值得注意的地方是在9655行中，sync落盘缓存之前会等到binlog_group_commit_sync_delay毫秒或收集到binlog_group_commit_sync_no_delay_count个事务之后再sync。

3.2 change_stage和enroll_for

change_stage 函数主要的作用是将当期事务加入对应的队列中，并返回这个事务是否成为leader。函数关键代码如下所示：

 9140 bool   9141 MYSQL_BIN_LOG::change_stage(THD *thd,   9142                             Stage_manager::StageID stage, THD *queue,   9143                             mysql_mutex_t *leave_mutex,   9144                             mysql_mutex_t *enter_mutex)   9145 {            ... ...     9156   if (!stage_manager.enroll_for(stage, queue, leave_mutex))   9157   {   9158     DBUG_ASSERT(!thd_get_cache_mngr(thd)->dbug_any_finalized());   9159     DBUG_RETURN(true);   9160   }          ... ...        }  

在change_stage函数中主要调用了enroll_for函数进行注册，enroll_for函数关键代码如下：

 2149 bool   2150 Stage_manager::enroll_for(StageID stage, THD *thd, mysql_mutex_t *stage_mutex)   2151 {   2152   // If the queue was empty: we're the leader for this batch   2153   DBUG_PRINT("debug", ("Enqueue 0x%llx to queue for stage %d",   2154                        (ulonglong) thd, stage));   2155   bool leader= m_queue[stage].append(thd);   2156       			... ...     2213   if (!leader)   2214   {   2215     mysql_mutex_lock(&m_lock_done);   2216 #ifndef DBUG_OFF   2217     /*   2218       Leader can be awaiting all-clear to preempt follower's execution.   2219       With setting the status the follower ensures it won't execute anything   2220       including thread-specific code.   2221     */   2222     thd->get_transaction()->m_flags.ready_preempt= 1;   2223     if (leader_await_preempt_status)   2224       mysql_cond_signal(&m_cond_preempt);   2225 #endif   2226     while (thd->get_transaction()->m_flags.pending)   2227       mysql_cond_wait(&m_cond_done, &m_lock_done);   2228     mysql_mutex_unlock(&m_lock_done);   2229   }   2230   return leader;   2231 }  

在代码中可以看出在接入对应的队列后，如果发现当前事务不能成为leader 则会在后续调用条件变量进行休眠。当order_commit函数中，leader 完成了所有的任务，则在9760行使用条件变量唤醒其他Follower进程。follower进程会调用DBUG_RETURN(finish_commit(thd))完成commit并退出函数。

4. 小结

本文主要介绍了关于binlog组提交的逻辑。限于本文的作者水平有限，文中的错误在所难免，恳请大家批评指正。