提问：作为DBA运维的你，是否有过这些烦恼

1、业务系统进行替换投产时，发现数据库回放并行度低

2、虽然2个数据库集群使用同一份数据，却在关闭双一后，二级从库的回放效率依旧缓慢，不知是什么原因？

心中有章，遇事不慌

作为DBA的你，遇到问题无从下手，除了在问题面前徘徊，还能如何选择？如果你一次或多次遇到该问题还是无法解决，又很懊恼，该如何排忧呢？关注公众号，关注《包拯断案》专栏，让小编为你排忧解难~

#包拯秘籍#

一整套故障排错及应对策略送给你，让你像包拯一样断案如神：

 #首先

遇到此类问题后，我们要做到心中有章（章程），遇事不慌。一定要冷静，仔细了解故障现象（与研发/用户仔细沟通其反馈的问题，了解故障现象、操作流程、数据库架构等信息）

#其次

我们要根据故障现象进行初步分析。心中要想：是什么原因导致回放数据慢？例如：是二级从库出了问题，还是资源遇到瓶颈？

#然后

针对上述思考，我们需要逐步验证并排除，确定问题排查方向。

#接着

确定了问题方向，进行具体分析。通过现象得出部分结论，通过部分结论继续排查并论证。

#最后

针对问题有了具体分析后，再进行线下复现，最终梳理故障报告。

真刀实战，我们能赢

说了这么多理论，想必实战更让你心动。那我们就拿一个真实案例进行分析---某国有大型商业银行子业务系统要进行替换投产，在替换过程中遇到回放数据慢的问题，该如何快速分析处理：

1.故障发生场景

在项目现场兢兢业业准备数据库替换上线的你，正计划把客户子业务系统中的数据库从MySQL 5.7.21 替换到GreatDB最新版本，该业务系统采用主从级联复制，原计划流程如下：

1. 停止旧环境的一台从库（以下称“一级从库”），使用冷备方式拷贝一份数据文件副本到新环境。在新环境上使用原地替换的方式，将数据文件替换为GreatDB最新版本（以下称“二级从库”）；

2.  第二天晚上，启动之前停止的一级从库，将二级从库主从连接到一级从库上，两库开始追赶近3天的增量数据；

3. 第三天凌晨，发现两台从库应用增量数据缓慢，磁盘iops高。为加快追赶增量数据速度，关闭两台库的双一参数，iops显著下降。一段时间后，一级从库接近追平数据，而二级从库则回放缓慢。发现二级从库资源使用率较低，没有瓶颈，因此利用show processlist 查看worker进程，发现回放并行度低，只能中止替换投产工作。

（示意图）

（何为“双一”：即系统变量 sync_binlog = 1 和 innodb_flush_log_at_trx_commit = 1，以便从库的二进制日志和redo log 能即时同步到磁盘，否则已提交的二进制日志可能因意外宕机而丢失。）

2.故障分析

一级从库和二级从库使用同一份数据，在关闭双一之前未看到明显的延迟差异。关闭双一后，一级从库回放速度大幅提升，二级从库回放效率依旧缓慢。正常情况下，如果资源没有瓶颈，二级从库应该会出现回放并行度下降的问题。

3.原理分析：结合并行复制原理进行分析

1）基本原理

通过事务分组，优化减少了生成二进制日志所需的操作数。当事务同时提交时，它们将在单个操作中写入二进制日志。若事务能同时提交成功，则它们不会共享任何锁，这就意味着它们没有冲突，可以在Slave上并行执行。

2）事务合并机制

binlog中的事务记录了两个值：

• last_commit：上个事务的提交顺序号

• sequence_number：本次事务的提交顺序号

根据组提交和两阶段提交机制，last_commit值可以合并，即相近事务可以具有相同的last_commit值。事务分发时，last_commit work线程会检查事务的last_commit， last_commit对应的上一事务完成提交后，本事务才能进行回放。last_commit相同的事务，可同时通过分发阶段，即可以并行执行。

3）last_commit值的产生方式

事务提交时，可分成以下三个阶段：

• Stage 1：prepare

   获取全局的提交号，固定为事务的last_commit值，进行innodb redo prepare。

• Stage 2：binlog flush

  进行redo刷盘，获得innodb_flush_log_at_trx_commit 的生效点。将事务信息写入binlog并进行刷盘，则获得了sync_binlog 的生效点。

• Stage 3：commit

  进行innodb commit，更新全局提交号。

由于redo和binlog全局只有一份，因此此处只能串行执行。每个Stage同一时间只允许一个线程操作，其它线程的事务将进入每个stage设置的等待队列。为提高效率，此时需引入组提交机制。当一个线程获得执行stage的执行权限时，会将【等待队列】中的事务合并执行提交任务。因此，各阶段可以同时存在多个事务。在一定时间内，通过stage 1提交的事务，则具有了相同的last_commit值。

4）关闭双一下的last_commit

当双一关闭，执行stage 1和stage 2的时间就会大幅压缩，等待队列积累的事务长度会减少，提交就会很快进入Stage 3阶段，全局提交号递增频率增加。binlog中事务记录的last_commit值就会快速递增。从库使用读取这份binlog进行回放，并行度就下降了。

   

如下图所示，关闭双一后，stage 1和stage 2的执行时间大幅压缩：

如下图所示，开启双一情况下，一级从库binlog的last_commit。二级从库回放时，8号事务完成后，9-16号事务可以并行回放。

   

如下图所示，关闭双一情况下，一级从库binlog的last_commit。二级从库回放时，8号事务完成后，只有9号事务的last_commit为8，退化为串行回放。

  

    

下图为复制链路示意图：关闭双一前，一级/二级从库能高并发回放。关闭双一后，二级从库并发降级。

4.故障优化方案

由于级联复制追赶增量数据时，既要考虑释放IO能力，也要兼顾降低last_commit的递增数。

因此，可以参考以下方法：

1）设置innodb_flush_log_at_trx_commit=0，sync_binlog=1

sync_binlog保持为1，减缓事务进入Stage 3，降低【全局提交号】的递增速度，保护并行度。

设置innodb_flush_log_at_trx_commit=0，降低IO消耗。同时，事务进入stage 1的效率提升，获取相同last_commit的概率增大。

2） 设置slave_preserve_commit_order=0

若事务是回放线程发起的，在开启slave_preserve_commit_order情况下，事务进入Stage 1等待队列前，会先进入排队状态，以保证从库事务提交顺序和主库保持一致，保护事务提交时间的线性增加。与此同时，会延缓事务进入stage 1队列，降低提交效率和并行度。从库延迟大时，可以考虑关闭。这个操作在高并发场景时效果尤其明显。

3）优化刷脏，释放iops能力

关闭double write，增大redo，增大buffer_pool，提高脏页低水位线，调整innodb_io_capacity等。通过调整刷脏相关参数，减少刷脏消耗的磁盘IO。

4）不建议从库调整组提交等待参数

binlog_group_commit_sync_no_delay_count，这一参数受限于从库并发量，很难稳定触发。

binlog_group_commit_sync_delay ，这一参数受限于从库并行执行，无法通过此参数合并大量事务提交，容易进入无意义的空等，反而减慢事务回放。

5）改变last_commit算法（针对MySQL5.7.22以上版本，GreatDB全系版本支持） 

MySQL5.7.22引入了新的last_commit计算方法，提高并行度。

设置参数如下：

-   transaction_write_set_extraction=XXHASH64

-   binlog_transaction_dependency_tracking=WRITESET/WRITESET_SESSION

  

开启后，事务提交会将改变的行保存在内存写集合中。新事务提交会比对写集合，没有冲突则不递增last_commit。冲突则清空写集合，并改变last_commit，此举可大幅提高并行度。

复盘总结

01

投产暂停原因：

本次替换投产工作暂停，是级联复制二级从库回放并行度低引起的，造成二级从库大幅度延迟。主要是MySQL的级联复制机制引起的，而非GreatDB问题。

02

维护措施：

替换过程中，一定要做好监控及定期巡检，确保数据库处于稳定运行状态；

03

替换优化方案：

1）替换方案：

针对冷备数据目录目前间隔两天才启动二级从库追平数据的方案，可以优化替换策略：缩短二级从库冷备目录到开始追平数据之间的时间差（1天内），保证二级从库实际可用的回放时间；

2）后期优化方案：

a.优化slave_preserve_commit_order、innodb_flush_log_at_trx_commit、sync_binlog等数据库参数，以提升磁盘能力；

b.修改并行复制算法”WRITESET“，大幅提升并行度能力。