目标：什么导致备库延迟，怎么解决备库延迟问题
备库延迟的原因
- binlog传送开销较小，主要是备库消费relaylog耗时比较多
- 备库的性能不如主库
- 备库承担了很多分析的SQL（例如：备库做数据分析，数据统计）
- 主库的长事务未提交
- 主库是多线程、多用户并发的处理数据，备库是单线程单用户（主要原因）
处理方法
基本处理方法
- 主备使用相同配置的机器（时刻准备顶替主库的备库，理应使用相同配置）
- 备库关闭log实时落盘
- 增加从库的数量，分析的SQL、定时任务尽量在业务低峰运行
- binlog传送至大数据分析系统，不要选用mysql，选用转门分析的数据库
- 长事务，拆分成多个小事务，拆分的去提交事务
从库并行复制方法
该方法是5.6引入的
mysql5.6使用按库并行策略
- 优点：分发选择快，支持各种log格式
- 缺点：按库分发粒度太大了，很难负载平衡
- 开启方式：slave-parallel-type = DATABASE
mysql5.7使用按事务组并行策略
备库可以同时应用多个事务，只要这些事务在主库上是独立的（也就是说，它们不会相互冲突）
事务组并行策略
- 同时处于prepare状态的事务，在备库执行时是可以并行的
- 开启方式：slave-parallel-type = LOGICAL_CLOCK
- binlog_group_commit_sync_delay：延迟多少微妙后才调用fsync
- binlog_group_commit_sync_no_delay_count：累积多少次以后才调用fsync
5.7.22新参数
binlog-transaction-dependency-tracking参数：
- COMMIT_ORDER：按事务组并行（5.7）
- WRITESET：没有修改相同行的事务可以并行
- WRITESET_SESSION：同一个线程先后执行的两个事务不能并行
怎么样才能读到最新的数据
- 强制实时性强的业务，敏感业务，读主库
- 在前端业务增加读取进度条，按照备库延迟的时间去按需增加
- 对比binlog执行位点
- 对比GTID执行的情况
理论上来讲从库的延迟是无法被消灭的。
-- 从库
-- 等待binlog位点
select master_pos_wait(file, pos[, timeout]);
-- 等待GTID（5.7.6之后可以返回每次事务的GTID）
select wait_for_executed_gtid_set(gtid_set, 1);
Comments NOTHING