同步延迟问题

最近更新时间:2019-08-15 10:25:44

同步延迟影响

云数据库 MySQL 对应的默认备库、灾备实例、只读实例均采用 MySQL 原生 binlog 复制技术,当数据复制方式为异步复制或半同步复制时,都有可能发生延迟。

  • 备库 存在延迟,会导致主备实例无法在短时间内完成切换,进而影响业务无法在短时间内恢复正常。
  • 灾备实例 存在延迟,在堆积的 binlog 未应用完之前,灾备实例将无法顺利升级为主实例,在此期间业务的连续性会因此受到影响。
  • 若读业务对数据一致性有较高要求,只读组 可以设置延迟剔除策略,当只读实例与主实例延迟时间超过阈值,对应的只读实例会被自动剔除,从而导致读业务无法正常访问只读实例。

同步延迟解决方案

通过 监控功能 可查看【主从延迟时间】,若主从延迟时间大于0表示其实例存在数据延迟。常见原因如下:

无主键或二级索引

原因
若 binlog 为 row 格式且表无主键或二级索引,当对大表进行 DML 操作(例如 delete、update、insert),在从库进行 binlog 日志应用时,会根据主键或者二级索引来检索需要更改的行,如对应表未创建主键或者二级索引,会产生大量的全表扫描进而降低了日志应用速度,从而产生数据延迟。

解决方案

  • 为所有表创建主键,若表无法创建主键,建议选择基数高的列创建二级索引。
  • 建议采用 truncate 命令删除表所有记录。

大事务

原因
当主实例执行大数据量的 DML 操作,大量的 binlog 日志传送到从库时,从库需要花费与主实例相同的时间来完成相应事务,进而导致从库出现数据延迟。

解决方案
建议将大事务拆分为小事务,通过 where 条件限制每次要处理的数据量,有助于从库迅速完成事务的执行,从而避免出现从库数据的延迟。

DDL 操作

原因
与大事务原理类似,若 DDL 操作在主实例的执行时间很长,在从库也会花费相同甚至更长时间来执行该操作,从而阻塞了 DDL 操作。

解决方案
建议在业务低峰期执行 DDL 操作。若因灾备实例、只读实例的查询业务而阻塞了 DDL 操作,建议直接 KILL 掉引起阻塞的会话来恢复主从数据的同步。

实例规格过小

原因
只读实例、灾备实例的规格小于主实例且负载较高,会导致只读实例、灾备实例的数据延迟。

解决方案
建议只读实例、灾备实例规格大于等于主实例,如果只读实例、灾备实例承载了大量的分析类业务导致实例负载过高,需将其实例规格升级至合适的配置或者对其性能低效的 SQL 进行优化。