数据库
首页 > 数据库> > mysql复制那点事(2)-binlog组提交源码分析和实现

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

作者：互联网

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

[TOC]

0. 参考文献

序号 文献
1 MySQL 5.7 MTS源码分析
2 MySQL 组提交
3 MySQL Redo/Binlog Group Commit , 2pc事务两阶段提交，Crash Recovery浅析
4 MySQL · 物理备份 · Percona XtraBackup 备份原理
5 条件变量(Condition Variable)详解
6 Linux线程同步之条件变量

本文主要介绍了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阶段：

2阶段提交1

下面来说明下图中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 保证事务顺序提交的时候，为什么能够解决这个问题。

2阶段提交2

同样如上图所示，展示了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中提交的顺序不同)

组提交的流程如图所示：

组提交1

从上图中可以看出，每个阶段都会产生一个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。

order_commit

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并退出函数。

img

4. 小结

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

标签：binlog,...,源码,提交,mysql,commit,thd,stage
来源： https://www.cnblogs.com/bush2582/p/11338455.html