Mysql备库延迟太大,怎么办?

发布于 2023-05-15  195 次阅读


目标:什么导致备库延迟,怎么解决备库延迟问题

备库延迟的原因

  1. binlog传送开销较小,主要是备库消费relaylog耗时比较多
  2. 备库的性能不如主库
  3. 备库承担了很多分析的SQL(例如:备库做数据分析,数据统计)
  4. 主库的长事务未提交
  5. 主库是多线程、多用户并发的处理数据,备库是单线程单用户(主要原因)

处理方法

基本处理方法

  • 主备使用相同配置的机器(时刻准备顶替主库的备库,理应使用相同配置)
  • 备库关闭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:同一个线程先后执行的两个事务不能并行

怎么样才能读到最新的数据

  1. 强制实时性强的业务,敏感业务,读主库
  2. 在前端业务增加读取进度条,按照备库延迟的时间去按需增加
  3. 对比binlog执行位点
  4. 对比GTID执行的情况

理论上来讲从库的延迟是无法被消灭的。

 -- 从库
-- 等待binlog位点
select master_pos_wait(file, pos[, timeout]);

-- 等待GTID(5.7.6之后可以返回每次事务的GTID)
select wait_for_executed_gtid_set(gtid_set, 1);
届ける言葉を今は育ててる
最后更新于 2023-05-16