主备延时 - 简书

采集延时信息的命令：

show slave status;

查看 seconds_behind_master的值；

1. 有些部署条件下，备库所在机器的性能要比主库所在的机器性能差（或者备库都放在同一

个机器上，主要是竞争资源很激烈，特别是IO）；

2. 备库上的压力（备库上的查询可能耗费了大量的CPU资源，影响了同步的速度，造成了主

备延时。这种情况可以通过配置一主多从来分担备库的压力）；

3. 大事务（重点）

因为主库上必须等事务执行完成才会写入 binlog，再传给备库。所以，如果一个主库上的语句

执行 10 分钟，那这个事务很可能就会导致从库延迟 10 分钟。

大事务场景：

1）不要一次性地用 delete 语句删除太多数据。其实，这就是一个典型的大事务场景。

删除数据的时候，要控制每个事务删除的数据量，分成多次删除。

2）大表 DDL

建议使用 gh-ost 方案

4. 备库的并行复制能力

MySQL官方在MySQL5.6以后支持sql_thread线程多线程进行复制。

5. 主库DML语句并发大，从库的qps高；

6. 主库和从库的参数配置不一样

7. 从库上在进行备份操作

8. 备库空间不足的情况下

9. 表上无主键的情况(主库利用索引更改数据,备库回放只能用全表扫描,这种情况可以调整slave_rows_search_algorithms参数适当优化下)

检查锁情况：

show engine innodb status\G;

由于主备延迟的存在，所以在主备切换的时候，就相应的有不同的策略。

1. 可靠性优先策略

2. 可用性优先策略

MySQL 5.7 的并行复制策略

由参数 slave-parallel-type 来控制并行复制策略：

1. 置为 DATABASE，表示使用 MySQL 5.6 版本的按库并行策略；

2. 配置为 LOGICAL_CLOCK，表示的就是类似 MariaDB 的策略。不过，

MySQL 5.7 这个策略，针对并行度做了优化。

MySQL 5.7 并行复制策略的思想是：

1. 同时处于 prepare 状态的事务，在备库执行时是可以并行的；

2. 处于 prepare 状态的事务，与处于 commit 状态的事务之间，在备库执行时也是可以并行的。

MySQL并行复制策略

MySQL 5.7.22版本，MySQL新增了基于WRITESET 的并行复制

通过参数 binlog-transaction-dependency-tracking来控制是否开启：

1. COMMIT_ORDER：根据同时进入 prepare 和 commit 来判断是否可以并行的策略。

2. WRITESET

表示的是对于事务涉及更新的每一行，计算出这一行的 hash 值，组成集合 writeset。

如果两个事务没有操作相同的行，也就是说它们的 writeset 没有交集，就可以并行。

3. WRITESET_SESSION

是在 WRITESET 的基础上多了一个约束，即在主库上同一个线程先后执行的两个事务，

在备库执行的时候，要保证相同的先后顺序。

这个 hash 值是通过“库名 + 表名 + 索引名 + 值”计算出来的。如果一个表上除了有主键索引

外，还有其他唯一索引，那么对于每个唯一索引，insert 语句对应的 writeset 就要多增加一个

hash 值。

优势：

1. writeset 是在主库生成后直接写入到 binlog 里面的，这样在备库执行的时候，不需要解

析 binlog 内容（event 里的行数据），节省了很多计算量；

2. 不需要把整个事务的 binlog 都扫一遍才能决定分发到哪个 worker，更省内存；