前言
本文主要介绍 MySQL 备库的并行复制策略。
为什么备库需要并行复制
如果主数据库有大量的更新操作，因为主数据库可以并发写入，而从数据库只能在单个线程中执行，那么从数据库的同步延迟将不断累积，即从数据库将越来越赶不上主数据库。因此，稍后会并行复制备用库。
[En]
If the master database has a large number of update operations, because the master database can be written concurrently, and the slave database can only be executed in a single thread, then the synchronization delay of the slave database will continue to accumulate, that is, the slave database will increasingly fail to catch up with the master database. Therefore, there is a parallel replication of the standby library later.
备库的并行复制模型：
coordinator 职责是分发 binlog 给工作线程，真正执行同步的是 worker。
按表分发策略
每个 worker 工作线程都对应一个表，coordinator 根据 binlog 内容将事务分发到不冲突的 worker 中并行执行，如果发生冲突，则等到不冲突的情况再分发到 worker 中执行。
以”数据库名 + 表名”为键，判断是否冲突：
- 如果待分发事务的键和 worker 存在键冲突数等于0，则选择空闲的 worker 执行；
- 如果待分发事务的键和 worker 存在键冲突数等于1，则选择冲突的 worker 执行；
- 如果待分发事务的键和 worker 存在键冲突数大于1，则等待直到前两个条件符合；
按行分发策略
与按表分配策略相同，但冲突的判断依据是数据库名+表名+主键名+主键值，还是数据库名+表名+唯一键名+唯一键值，需要计算更多的键。
[En]
It is the same as the distribution strategy by table, but the conflict is judged by “database name + table name + primary key name + primary key value” or “database name + table name + unique key name + unique key value”, and more keys need to be calculated.
为什么需要确定唯一密钥是否冲突？
[En]
Why do you need to determine whether a unique key conflicts?
由于并发执行的执行时间顺序与以前不同，可能会先执行先执行的事务，这可能会导致不符合唯一性约束和数据不一致。
[En]
Because the execution time sequence of concurrent execution is not the same as before, the transactions that were executed first may be executed first, which may lead to non-compliance with uniqueness constraints and data inconsistency.
组提交并行策略
MariaDB 提出的并行复制策略
MySQL 组提交的前提是组里面的事务是不冲突的，或者说并行执行不影响数据一致性的。组提交时，在 binlog 中记录 commit_id，那么在备库分发时，将同一个 commit_id 的事务分到不同的 worker 并行执行。
不过，这个方法存在一个缺陷。备库每次执行分发同一个 commit_id 下的事务到 worker 中执行，等都执行完之后，才可以分发下一个 commit_id 对应的事务。这样的话，备库并不是真正地在并行复制，并且，如果一个 commit_id 下的某个事务是大事务，那么将导致下一组执行的时间延后，即存在”短板效应”。
组提交优化策略
MySQL5.7 提出的并行复制策略，在 MariaDB 并行复制策略上进行了优化。
根据 MySQL 两阶段提交，只要处于 prepare 阶段的事务就可以并行执行。所以，下面情况下的事务都可以并行执行：
- 同时处于 prepare 的事务
- 处于 prepare 和 commit 之间的事务
write_set策略
在主库写入 binlog 之前，计算事务涉及的每一行的 hash 值，写入 binlog，这样在备库分发的时候就不需要解析 binlog 来判断，只需要判断两个事务是否有交集来判断是否可以并行，提交运行效率。
因为不需要解析 binlog 来获取信息，所以该方法下， binlog 采用 statement 和 row 格式都可以。
此外，还有 write_set_session 策略，它在 write_set 策略上加了一个约束，同一个线程先后执行的两个事务，在备库复制时不能并行。
参考
- [1] 备库为什么会延迟好几个小时
Original: https://www.cnblogs.com/flowers-bloom/p/mysql45-slave-async-copy.html
Author: flowers-bloom
Title: MySQL45讲之备库并行复制策略
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/508072/
转载文章受原作者版权保护。转载请注明原作者出处！