mysql 主从延时问题

过线上 MySQL 维护经验的童鞋都知道，主从延迟往往是一个让人头疼不已的问题。

不仅仅是其造成的潜在问题比较严重，而且主从延迟原因的定位尤其考量 DBA 的综合能力：既要熟悉复制的内部原理，又能解读主机层面的资源使用情况，甚至还要会分析 binlog。

导致主从延迟的一个常见原因是，对于 binlog 中的事务，从库上只有一个 SQL 线程进行重放，而这些事务在主库中是并发写入的。

就好比你多个人（多线程）挖坑，我一个人（单线程）来填，本来就双拳难敌四手，在你挖坑速度不快的情况下，我尚能应付。一旦你稍微加速，我则力有不逮，只能眼睁睁地看着你挖的坑越来越深。

具体在 MySQL 中，则意味着 Seconds_Behind_Master 的值越来越大。

本文主要包括以下几部分：

主从延迟的危害
并行复制方案简介
MySQL 5.7 基于组提交的并行复制方案，包括 Commit-Parent-Based 方案和 Lock-Based 方案
MySQL 8.0 基于 WRITESET 的并行复制方案
对 COMMIT_ORDER，WRITESET_SESSION，WRITESET 这三种方案的压测结果
如何开启并行复制

一、主从延迟的危害

主从延迟带来的问题，主要体现在以下两个方面：

1、对于读写分离的业务，主从延迟意味着业务会读到旧数据。

2、主从延迟过大，会影响数据库的高可用切换。这一点尤其需要注意。

如果等待从库应用完差异的 binlog 才做高可用切换，无疑会影响数据库服务的可用性。

如果不等待，直接切换，则意味着没应用完的这部分 binlog 的数据会丢失，业务不一定能接受这种情况。

二、并行复制方案简介

MySQL官方先后提出了多个不同的并行复制方案，具体如下。

MySQL 5.6 基于库级别的并行复制方案。
MySQL 5.7 基于组提交的并行复制方案。
MySQL 8.0 基于 WRITESET 的并行复制方案。

因为线上大部分环境都是单库多表的，所以基于库级别的并行复制实际上用得并不多。

下面，重点看看后两个方案的实现原理。

三、基于组提交的并行复制方案

MySQL 5.7 基于组提交的并行复制方案，先后经历了两个版本的迭代：Commit-Parent-Based 方案和 Lock-Based 方案。

3.1 Commit-Parent-Based 方案

MySQL 会将一个事务拆分为两个阶段进行处理：Prepare 阶段和 Commit 阶段。

另外，InnoDB 使用的锁机制是悲观锁。在悲观锁中，事务是在操作之初执行加锁操作，如果锁资源被其它事务占用了，则该事务会被阻塞。

基于这两点，我们不难推断出，两个事务如果都进入了 Prepare 阶段，则意味着它们之间是没有锁冲突的，在从库重放时可并行执行。这就是 Commit-Parent-Based 方案的核心思想。

具体实现上：

1、主库有个全局计数器（global counter），每次在事务存储引擎层提交之前，都会增加这个计数器。

2、在事务进入 Prepare 阶段之前，会将全局计数器的当前值记录在事务中，这个值称为事务的 commit-parent。

3、这个 commit-parent 会写入 binlog，记录在事务的头部。

4、从库重放时，如果发现两个事务的 commit-parent 相同，会并行执行这两个事务。

以下面这 7 个事务为例，看看这 7 个事务在从库的并行执行情况。

Trx1 ------------P----------C-------------------------------->                            |Trx2 ----------------P------+---C---------------------------->                            |   |Trx3 -------------------P---+---+-----C---------------------->                            |   |     |Trx4 -----------------------+-P-+-----+----C----------------->                            |   |     |    |Trx5 -----------------------+---+-P---+----+---C------------->                            |   |     |    |   |Trx6 -----------------------+---+---P-+----+---+---C---------->                            |   |     |    |   |   |Trx7 -----------------------+---+-----+----+---+-P-+--C------->                            |   |     |    |   |   |  |

示例中的 Trx 指的是事务，P 指的是事务在进行 Prepare 阶段之前，读取 commit-parent 的时间点。C 指的是事务在进行 Commit 阶段之前，增加全局计数器的时间点。

下面看看这 7 个事务的并行执行情况。

Trx1、Trx2、Trx3 并行执行

Trx4 串行执行

Trx5、Trx6 并行执行

Trx7 串行执行

这在很大程度上实现了并行，但还不够完美。

实际上，Trx4、Trx5、Trx6 可并行执行，因为它们同时进入了 Prepare 阶段。同理，Trx6、Trx7 也可并行执行。

基于此，官方迭代了并行复制方案，推出了新的 Lock-Based 方案。

3.2 Lock-Based 方案

该方案引入了锁区间（locking interval）的概念，锁区间定义了一个事务持有锁的时间范围。具体来说，

将 Prepare 阶段，最后一个 DML 语句获取锁的时间点，定义为锁区间的开始点
将存储引擎层提交之前，锁释放的时间点，定义为锁区间的结束点

如果两个事务的锁区间存在交集，则意味着这两个事务没有锁冲突，可并行重放。例如，

Trx1 -----L---------C------------>Trx2 ----------L---------C------->

反之，则不可并行重放，例如，

Trx1 -----L----C----------------->Trx2 ---------------L----C------->

这里的 L 代表锁区间的开始点，C 代表锁区间的结束点。

在具体实现上，主库引入了以下 4 个变量：

global.transaction_counter：事务计数器
transaction.sequence_number：事务序列号

在事务进入 Prepare 阶段之前，会将 global.transaction_counter 自增加 1 并赋值给 transaction.sequence_number 。

transaction.sequence_number = ++global.transaction_counter

序列号不是一直递增的，每切换一个 binlog，都会将 transaction.sequence_number 重置为 1。

3、global.max_committed_transaction：当前已提交事务的最大序列号。

在事务进行存储引擎层提交之前，会取 global.max_committed_transaction 和当前事务的 sequence_number 的最大值，赋值给 global.max_committed_transaction。

global.max_committed_transaction = max(global.max_committed_transaction,                                           transaction.sequence_number)

4、transaction.last_committed：在事务进入 Prepare 阶段之前，已提交事务的最大序列号。

transaction.last_committed = global.max_committed_transaction

在这 4 个变量中，transaction.sequence_number 和 transaction.last_committed 会写入 binlog。

具体来说，对于 GTID 复制，它们会写入 GTID_LOG_EVENT；对于非 GTID 复制，则写入 ANONYMOUS_GTID_LOG_EVENT 。

对于示例中的 7 个事务，记录在 binlog 中的 last_committed、sequence_number 如下所示：

Trx1: last_committed=0 sequence_number=1Trx2: last_committed=0 sequence_number=2Trx3: last_committed=0 sequence_number=3Trx4: last_committed=1 sequence_number=4Trx5: last_committed=2 sequence_number=5Trx6: last_committed=2 sequence_number=6Trx7: last_committed=5 sequence_number=7

3.3 从库并行重放的逻辑

下面说说从库并行重放的逻辑。

从库引入了一个事务队列（ transaction_sequence ），包含了当前正在执行的事务。

该队列是有序的，按照事务的 sequence_number 从小到大排列。这个队列中的事务可并行执行。

一个新的事务能否插入这个队列，唯的判断标准是，事务的 last_committed 是否小于队列中第一个事务的 sequence_number。只有小于才允许插入。

transaction.last_committed < transaction_sequence[0].sequence_number

最后，回到示例中的 7 个事务，结合 binlog 中的 last_committed 和 sequence_number，我们看看这 7 个事务的并行执行情况。

Trx1、Trx2、Trx3 并行执行

Trx1 执行完毕后，Trx4 可加入队列

Trx2 执行完毕后，Trx5、Trx6 可加入队列

Trx5 执行完毕后，Trx7 可加入队列

不难发现，相对于 Commit-Parent-Based 方案，Lock-Based 方案的并行度确实大大提高了。

3.4 组提交方案小结

无论是 Commit-Parent-Based 方案，还是 Lock-Based 方案，依赖的都是组提交（Group Commit）。

组提交方案有以下两个特点：

适用于高并发场景。因为只有在高并发场景下，才会有更多的事务放到一个组（Group）中提交。
在级联复制中，层级越深，并行度越低。

针对低并发场景，如果要提升从库的并行效率，可调整以下两个参数：

binlog_group_commit_sync_delay

binlog 刷盘（fsync）之前等待的时间。单位微秒，默认为 0，不等待。

该值越大，一个组内的事务就越多，相应地，从库的并行度也就越高。但该值越大，客户端的响应时间也会越长。

binlog_group_commit_sync_no_delay_count

在 binlog_group_commit_sync_delay 时间内，允许等待的最大事务数。

如果 binlog_group_commit_sync_delay 设置为 0，则此参数无效。

四、WRITESET 方案

MySQL 8.0 推出了 WRITESET 方案。该方案推出的初衷实际上是为 Group Replication 服务的，主要是用于认证阶段（Certification）的冲突检测。

WRITESET 方案的核心思想是，两个来自不同节点的并发事务，只要没修改同一行，就不存在冲突。对于没有冲突的并发事务，在写入relay log 中时，可以共享一个 last_committed。

这里的冲突检测，实际上比较的是两个事务之间的写集合（writeset）。

注意，writeset 和 WRITESET 两者的区别，前者指的是事务的写集合，后者则特指 WRITESET 方案。

4.1 事务写集合的生成过程

下面来看看事务 writeset 的生成过程。具体步骤如下：

1、首先提取被修改行的主键、唯索引、外键信息。一张表，如果有主键和一个索引，则每修改一行，会提取两条约束信息：一条针对主键，另一条针对索引。针对主键的，提取的信息包括主键名、库名、表名、主键值，这些信息会拼凑为一个字符串。

2、计算该字符串的哈希值，具体的哈希算法由 transaction_write_set_extraction 参数指定。

3、将计算后的哈希值插入当前事务的写集合。

4.2 WRITESET 方案的实现原理

接下来，结合源码看看 WRITESET 方案的实现原理。



void Writeset_trx_dependency_tracker::get_dependency(THD *thd,


                                                     int64 &sequence_number,



                                                     int64 &commit_parent) {

  Rpl_transaction_write_set_ctx *write_set_ctx =

      thd->get_transaction()->get_transaction_write_set_ctx();

  std::vector<uint64> *writeset = write_set_ctx->get_write_set();




#ifndef NDEBUG

  /* 空事务的写集合必须为空 */

  if (is_empty_transaction_in_binlog_cache(thd)) assert(writeset->size() == 0);

#endif




  /*

    判断一个事务能否使用 WRITESET 方案

  */

  bool can_use_writesets =

      // 事务写集合的大小不为 0 或者事务为空事务

      (writeset->size() != 0 || write_set_ctx->get_has_missing_keys() ||

       is_empty_transaction_in_binlog_cache(thd)) &&

      // 事务的 transaction_write_set_extraction 必须与全局设置一致

      (global_system_variables.transaction_write_set_extraction ==

       thd->variables.transaction_write_set_extraction) &&

      // 不能被其它表外键关联

      !write_set_ctx->get_has_related_foreign_keys() &&

      // 事务写集合的大小不能超过 binlog_transaction_dependency_history_size

      !write_set_ctx->was_write_set_limit_reached();

  bool exceeds_capacity = false;




  if (can_use_writesets) {

    /*

     检查 m_writeset_history 加上事务写集合的大小是否超过 m_writeset_history 的上限，

     m_writeset_history 的上限由参数 binlog_transaction_dependency_history_size 决定 

    */

    exceeds_capacity =

        m_writeset_history.size() + writeset->size() > m_opt_max_history_size;




    /*

     计算所有冲突行中最大的 sequence_number，并将被修改行的哈希值插入 m_writeset_history

    */

    int64 last_parent = m_writeset_history_start;

    for (std::vector<uint64>::iterator it = writeset->begin();

         it != writeset->end(); ++it) {

      Writeset_history::iterator hst = m_writeset_history.find(*it);

      if (hst != m_writeset_history.end()) {

        if (hst->second > last_parent && hst->second < sequence_number)

          last_parent = hst->second;




        hst->second = sequence_number;

      } else {

        if (!exceeds_capacity)

          m_writeset_history.insert(

              std::pair<uint64, int64>(*it, sequence_number));

      }

    }

    // 如果表上都存在主键，则会取 last_parent 和 commit_parent 的较小值作为事务的 commit_parent。if (!write_set_ctx->get_has_missing_keys()) {

      commit_parent = std::min(last_parent, commit_parent);

    }

  }




  if (exceeds_capacity || !can_use_writesets) {

    m_writeset_history_start = sequence_number;

    m_writeset_history.clear();

  }

}