备库并行复制能力

image.png

图 1 主备流程图

谈到主备的并行复制能力，我们要关注的是图中黑色的两个箭头。一个箭头代表了客户端写入主库，另一箭头代表的是备库上 sql_thread 执行中转日志（relay log）。如果用箭头的粗细来代表并行度的话，那么真实情况就如图 1 所示，第一个箭头要明显粗于第二个箭头。

而日志在备库上的执行，就是图中备库上 sql_thread 更新数据 (DATA) 的逻辑。如果是用单线程的话，就会导致备库应用日志不够快，造成主备延迟。

  • 在官方的 5.6 版本之前，MySQL 只支持单线程复制，由此在主库并发高、TPS 高时就会出现严重的主备延迟问题。

MySQL 多线程复制的演进过程

其实说到底，所有的多线程复制机制，都是要把图 1 中只有一个线程的 sql_thread，拆成多个线程，也就是都符合下面的这个模型：

image.png

图 2 多线程模型

  • coordinator 就是原来的 sql_thread, 不过现在它不再直接更新数据了，只负责读取中转日志和分发事务。真正更新日志的，变成了 worker 线程。而 work 线程的个数，就是由参数 slave_parallel_workers 决定的。

事务能不能按照轮询的方式分发给各个 worker?

  • 不行, 由于 CPU 的调度策略，很可能第二个事务最终比第一个事务先执行

同一个事务的多个更新语句，能不能分给不同的 worker 来执行呢？

  • 不行, 隔离性问题

coordinator 在分发的时候，需要满足以下这两个基本要求：

  • 不能造成更新覆盖。这就要求更新同一行的两个事务，必须被分发到同一个 worker 中。
  • 同一个事务不能被拆开，必须放到同一个 worker 中。

MySQL 5.5 版本的并行复制策略

按表分发策略

如果两个事务更新不同的表，它们就可以并行。因为数据是存储在表里的，所以按表分发，可以保证两个 worker 不会更新同一行。

  • 如果有跨表的事务，还是要把两张表放在一起考虑的

image.png

图 3 按表并行复制程模型

每个 worker 线程对应一个 hash 表，用于保存当前正在这个 worker 的“执行队列”里的事务所涉及的表。hash 表的 key 是“库名. 表名”，value 是一个数字，表示队列中有多少个事务修改这个表。

  • 在有事务分配给 worker 时，事务里面涉及的表会被加到对应的 hash 表中。worker 执行完成后，这个表会被从 hash 表中去掉。

图 3 中，hash_table_1 表示，现在 worker_1 的“待执行事务队列”里，有 4 个事务涉及到 db1.t1 表，有 1 个事务涉及到 db2.t2 表；hash_table_2 表示，现在 worker_2 中有一个事务会更新到表 t3 的数据。

假设在图中的情况下，coordinator 从中转日志中读入一个新事务 T，这个事务修改的行涉及到表 t1 和 t3。

分配规则:

  1. 由于事务 T 中涉及修改表 t1，而 worker_1 队列中有事务在修改表 t1，事务 T 和队列中的某个事务要修改同一个表的数据，这种情况我们说事务 T 和 worker_1 是冲突的。
  2. 按照这个逻辑，顺序判断事务 T 和每个 worker 队列的冲突关系，会发现事务 T 跟 worker_2 也冲突。
  3. 事务 T 跟多于一个 worker 冲突，coordinator 线程就进入等待。
  4. 每个 worker 继续执行，同时修改 hash_table。假设 hash_table_2 里面涉及到修改表 t3 的事务先执行完成，就会从 hash_table_2 中把 db1.t3 这一项去掉。
  5. 这样 coordinator 会发现跟事务 T 冲突的 worker 只有 worker_1 了，因此就把它分配给 worker_1。
  6. coordinator 继续读下一个中转日志，继续分配事务。

每个事务在分发的时候，跟所有 worker 的冲突关系包括以下三种情况：

  • 如果跟所有 worker 都不冲突，coordinator 线程就会把这个事务分配给最空闲的 woker;
  • 如果跟多于一个 worker 冲突，coordinator 线程就进入等待状态，直到和这个事务存在冲突关系的 worker 只剩下 1 个；
  • 如果只跟一个 worker 冲突，coordinator 线程就会把这个事务分配给这个存在冲突关系的 worker。

按行分发策略

如果两个事务没有更新相同的行，它们在备库上可以并行执行。显然，这个模式要求 binlog 格式必须是 row。

  • 这时候的 key，就必须是“库名 + 表名 + 唯一键的值”。
  • 这个“唯一键”只有主键 id 还是不够的，我们还需要考虑下面这种场景，表 t1 中除了主键，还有唯一索引 a：
  1. CREATE TABLE `t1` (
  2.   `id` int(11) NOT NULL,
  3.   `a` int(11) DEFAULT NULL,
  4.   `b` int(11) DEFAULT NULL,
  5.   PRIMARY KEY (`id`),
  6.   UNIQUE KEY `a` (`a`)
  7. ) ENGINE=InnoDB;
  9. insert into t1 values(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5);

image.png

图 4 唯一键冲突示例

这两个事务要更新的行的主键值不同，但是如果它们被分到不同的 worker，就有可能 session B 的语句先执行。这时候 id=1 的行的 a 的值还是 1，就会报唯一键冲突。

  • 基于行的策略，事务 hash 表中还需要考虑唯一键，即 key 应该是“库名 + 表名 + 索引 a 的名字 +a 的值”。

因此，coordinator 在解析这个语句的 binlog 的时候，这个事务的 hash 表就有三个项:

  • key=hash_func(db1+t1+“PRIMARY”+2), value=2; 这里 value=2 是因为修改前后的行 id 值不变，出现了两次。
  • key=hash_func(db1+t1+“a”+2), value=1，表示会影响到这个表 a=2 的行。
  • key=hash_func(db1+t1+“a”+1), value=1，表示会影响到这个表 a=1 的行。

这两个方案其实都有一些约束条件：

  • 要能够从 binlog 里面解析出表名、主键值和唯一索引的值。也就是说，主库的 binlog 格式必须是 row；
  • 表必须有主键；
  • 不能有外键。表上如果有外键，级联更新的行不会记录在 binlog 中，这样冲突检测就不准确。

如果是要操作很多行的大事务的话，按行分发的策略有两个问题：

  • 耗费内存。比如一个语句要删除 100 万行数据，这时候 hash 表就要记录 100 万个项。
  • 耗费 CPU。解析 binlog，然后计算 hash 值，对于大事务，这个成本还是很高的。

MySQL 5.6 版本的并行复制策略

官方 MySQL5.6 版本，支持了并行复制，只是支持的粒度是按库并行。理解了上面介绍的按表分发策略和按行分发策略，你就理解了，用于决定分发策略的 hash 表里，key 就是数据库名。

MariaDB 的并行复制策略

在第 23 篇文章中，我给你介绍了 redo log 组提交 (group commit) 优化， 而 MariaDB 的并行复制策略利用的就是这个特性.

  • 能够在同一组里提交的事务，一定不会修改同一行；
  • 主库上可以并行执行的事务，备库上也一定是可以并行执行的。

过程:

  1. 在一组里面一起提交的事务，有一个相同的 commit_id，下一组就是 commit_id+1；
  2. commit_id 直接写到 binlog 里面；
  3. 传到备库应用的时候，相同 commit_id 的事务分发到多个 worker 执行；
  4. 这一组全部执行完成后，coordinator 再去取下一批。

MySQL 5.7 的并行复制策略

在 MariaDB 并行复制实现之后，官方的 MySQL5.7 版本也提供了类似的功能，由参数 slave-parallel-type 来控制并行复制策略：

  • 配置为 DATABASE，表示使用 MySQL 5.6 版本的按库并行策略；
  • 配置为 LOGICAL_CLOCK，表示的就是类似 MariaDB 的策略。

MySQL 5.7.22 的并行复制策略

在 2018 年 4 月份发布的 MySQL 5.7.22 版本里，MySQL 增加了一个新的并行复制策略，基于 WRITESET 的并行复制。