高可用数据库主从复制延时的解决
DDL本身造成的延时难以避免,建议考虑:
◆ 案例四:主库与从库配置不一致 如果主库和从库使用了不同的计算资源和存储资源,或者使用了不同的内核调教参数,可能会造成主从不一致。 现象描述 我们会详细比对主库和从库的性能监控数据,如果发现监控数据差异巨大,结合查看主从的各个配置情况,即可作出明确判断。 原因分析 各种硬件或者资源的配置差异都有可能导致主从的性能差异,从而导致主从复制延时发生:
解决思路 考虑尽量统一DB机器的配置(包括硬件及选项参数)。甚至对于某些OLAP业务,从库实例硬件配置需要略高于主库。 ◆ 案例五:表缺乏主键或合适索引 如果数据库的表缺少主键或者合适索引,在主从复制的binlog_format设置为'row'的情况下,可能会产生主从复制延时。 现象描述 我们进行数据库检查时,会发现:
这些现象出现的情况下,可以认为很可能有表缺乏主键或唯一索引。 原因分析 在主从复制的binlog_format设置为'row'的情况下,比如有这样的一个场景,主库更新一张500万表中的20万行数据。binlog在row格式下,记录到binlog的为20万次update操作,也就是每次操作更新1条记录。如果这条语句恰好有不好的执行计划,如发生全表扫描,那么每一条update语句需要全表扫描。此时SQL Thread重放将特别慢,造成严重的主从复制延时。 解决思路 这种情况下,我们会去检查表结构,保证每个表都有显式自增主键,并协助用户建立合适索引。 ◆ 案例六:从库自身压力过大 有时候,从库性能压力很大的情况下,跟不上主库的更新速度,就产生了主从复制延时。 现象描述 观察数据库实例时,会发现CPU负载过高,IO利用率过高等现象,这些导致SQL Thread应用过慢。这样就可以判断是因为从库自身压力过大引起主从复制延时。 原因分析 部分UCloud用户对于数据库的主从会使用读写分离模式,读请求大部分在从库上执行。在业务有大量读请求的场景下,从库会产生比主库大得多的性能压力。有的用户甚至会在从库运行十分耗费计算资源的OLAP业务,这也对从库造成了更高的性能挑战,这些都会造成主从复制的延时。 解决思路 这种情况下,我们会建议用户建立更多从库,打散读请求,降低现有从库实例的压力。对于OLAP业务来说,可以专门建立一个从库来做OLAP业务,并对这个从库,允许适当的主从复制延时。 总结在使用MySQL的主从复制模式进行数据复制时,主从复制延时是一个需要考量的关键因素。它会影响数据的一致性,进而影响数据库高可用的容灾切换。 在遇到数据库之间出现主从复制延时的情况下,我们团队基于过往经验,归纳出以下方法与流程来协助排查问题:
UDB的高可用、高性能、便捷易用,可以大量减轻使用者的运维负担。在使用过程中, UDB团队也会利用多年累积的运营经验,帮助用户及时分析、排查问题原因,并给出合理的解决方法。 【编辑推荐】
点赞 0 (编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |