一条执行24s的SQL竟产生7小时数据延时，数据库高可用做了个寂寞

前言

数字时代，数据是企业的核心资产。为了确保企业应用程序的连续性和可靠性，数据库高可用性变得尤为重要。

高可用性（High Availability, HA）指的是系统在面临故障时仍能保持运行能力的特性。数据库高可用性意味着即使在硬件或软件故障的情况下，数据库服务仍然能够正常运行，并且数据不会丢失。

高可用性的基本指标：

• 可用性百分比：通常用来衡量系统可用性的标准，表示系统在一定时间内正常运行的比例。例如，99.99%的可用性表示每年仅有52分钟的停机时间。

• 故障转移时间：指系统从故障状态切换到正常运行状态所需的时间。

• 数据丢失时间窗口：在灾难或故障情况下，可能会丢失数据的时间段。

你的数据库真的高可用吗？

数据库要实现高可用的前提是需要至少存在一个备节点，且主备数据保持一致。而主备延时问题一直是高可用的头号难题。大家查看一下自己的数据库监控，是否存在有延时的数据库实例？

延时问题常见的来源有以下几种:

• 备库的主机性能比主库差

• 备库压力大

• 主库执行大事务

• 备库是未开启并行复制能力

• 主库大量数据写入

• 主备复制线程Bug Hang住

既想主库跑的快，又想没有延时，故障时还能秒级切换，这是所有运维DBA们追求的理想状态。尽管许多场景可以通过流程控制来优化，但面对由大事务或密集写入操作而引发的SQL性能问题，解决起来仍然非常棘手。那么，是否存在有效的策略来应对这些挑战呢？

如何识别SQL性能问题导致的延时？

近期我们却收到用户反馈说，他们的一个数据库主备延时7个小时，没有做大量写入，一直找不到原因，简直崩溃了，备库做了重搭换了一个机器还是出现同样的问题。使用了DBdoctor的性能洞察功能，最终找到了问题根因，下面我们来回顾一下MySQL这个案例。

备库延时现象：业务SQL没有大的数据量写入更新，但延时7小时，且发现备库的SQL线程执行位置不动。

手动问题分析

1）备库上查询等操作都很快，备库没有任何压力，硬件进程等资源指标都很正常，也没有业务连接访问执行SQL

2）查看系统表和innodb status，备库上也没有出现锁事件

3）通过备库错误日志和binlog分析，也未看出来有什么问题

4）查看复制线程状态，show slave status显示sql/io线程正常

DBdoctor工具分析

1）根据监控查看备库开始出现延时的时间，在DBdoctor工具的性能洞察功能上选中该延时的时间区间。发现出现延时上升的时间点数据库上新增了一条delete from xxx where month_y in (xxx,xxx,...)  24s的长事务异常，点击查询计划发现是全表扫描。

2）使用SQL审核功能，审核结果显示该SQL的 xxx表没有主键并推荐索引。

没有主键的慢SQL导致备库延时7个小时？

1）查看备库的binlog，发现binlog确实都是这个SQL的row记录。

2）binlog中的row记录没有主键，和主库的SQL一样。

相当于在主库执行的24s的SQL，由于binlog的row模式（没有主键id），每一条row都是一个24s的慢SQL，有多少条row就涉及多少个24s，在备库回放，这样就被放大到7个小时延时。

最终按照审核建议推荐的索引进行线上变更，主备延时问题得以解决。

结语

在当今数字化的时代，数据库的稳定和高效运行对于各行各业来说都是至关重要的。SQL语句作为数据库操作的基石，其质量和性能直接关系到整个系统的稳定性和安全性。DBdoctor作为一款领先的数据库性能诊断和优化工具，可以快速进行异常现场还原并根因定位，紧急救火。然而，要想实现数据库真正高可用，还需要拥有提前识别SQL性能问题的能力，DBdoctor的事前SQL审核覆盖性能审核，可以有效避免潜在事故的发生！

免费下载/在线试用：

https://dbdoctor.hisensecloud.com/col.jsp?id=126