前言
数字时代,数据是企业的核心资产。为了确保企业应用程序的连续性和可靠性,数据库高可用性变得尤为重要。
高可用性(High Availability, HA)指的是系统在面临故障时仍能保持运行能力的特性。数据库高可用性意味着即使在硬件或软件故障的情况下,数据库服务仍然能够正常运行,并且数据不会丢失。
可用性百分比:通常用来衡量系统可用性的标准,表示系统在一定时间内正常运行的比例。例如,99.99%的可用性表示每年仅有52分钟的停机时间。
故障转移时间:指系统从故障状态切换到正常运行状态所需的时间。
数据丢失时间窗口:在灾难或故障情况下,可能会丢失数据的时间段。
你的数据库真的高可用吗?
数据库要实现高可用的前提是需要至少存在一个备节点,且主备数据保持一致。而主备延时问题一直是高可用的头号难题。大家查看一下自己的数据库监控,是否存在有延时的数据库实例?
备库的主机性能比主库差
备库压力大
主库执行大事务
备库是未开启并行复制能力
主库大量数据写入
主备复制线程Bug Hang住
既想主库跑的快,又想没有延时,故障时还能秒级切换,这是所有运维DBA们追求的理想状态。尽管许多场景可以通过流程控制来优化,但面对由大事务或密集写入操作而引发的SQL性能问题,解决起来仍然非常棘手。那么,是否存在有效的策略来应对这些挑战呢?
如何识别SQL性能问题导致的延时?
近期我们却收到用户反馈说,他们的一个数据库主备延时7个小时,没有做大量写入,一直找不到原因,简直崩溃了,备库做了重搭换了一个机器还是出现同样的问题。使用了DBdoctor的性能洞察功能,最终找到了问题根因,下面我们来回顾一下MySQL这个案例。
1)备库上查询等操作都很快,备库没有任何压力,硬件进程等资源指标都很正常,也没有业务连接访问执行SQL
2)查看系统表和innodb status,备库上也没有出现锁事件
3)通过备库错误日志和binlog分析,也未看出来有什么问题
DBdoctor工具分析
1)根据监控查看备库开始出现延时的时间,在DBdoctor工具的性能洞察功能上选中该延时的时间区间。发现出现延时上升的时间点数据库上新增了一条delete from xxx where month_y in (xxx,xxx,...) 24s的长事务异常,点击查询计划发现是全表扫描。
2)使用SQL审核功能,审核结果显示该SQL的 xxx表没有主键并推荐索引。
没有主键的慢SQL导致备库延时7个小时?
1)查看备库的binlog,发现binlog确实都是这个SQL的row记录。
相当于在主库执行的24s的SQL,由于binlog的row模式(没有主键id),每一条row都是一个24s的慢SQL,有多少条row就涉及多少个24s,在备库回放,这样就被放大到7个小时延时。
最终按照审核建议推荐的索引进行线上变更,主备延时问题得以解决。
在当今数字化的时代,数据库的稳定和高效运行对于各行各业来说都是至关重要的。SQL语句作为数据库操作的基石,其质量和性能直接关系到整个系统的稳定性和安全性。DBdoctor作为一款领先的数据库性能诊断和优化工具,可以快速进行异常现场还原并根因定位,紧急救火。然而,要想实现数据库真正高可用,还需要拥有提前识别SQL性能问题的能力,DBdoctor的事前SQL审核覆盖性能审核,可以有效避免潜在事故的发生!
DBdoctor推出长久免费版
DBdoctor是一款企业级数据库全方位性能监控与诊断平台,致力于解决一切数据库性能问题。可以对商业数据库、开源数据库、国产数据库进行统一性能诊断。
具备:SQL审核、巡检报表、监控告警、存储诊断、审计日志、权限管理等免费功能,不限实例个数,可基于长久免费版快速搭建企业级数据库监控诊断平台。
同时拥有:性能洞察、锁分析、根因诊断、索引推荐、SQL发布前性能评估等高阶功能,官网可快速下载,零依赖,一分钟快速一键部署。