聊聊MySQL主从延迟

Posted 2023-04-08 Think_Higher

文章目录

• MySQL 的高可用是如何实现的呢？
• 二、什么是主备延迟？
• 三、主备延迟常见原因
• • 1、备库机器配置差
  • 2、备库干私活
  • 3、大事务
• 四、主库不可用，主备切换有哪些策略？
• • 1、可靠优先
  • 2、可用优先
  • • 实验一
    • 实验二
  • 3、结论

mysql 的高可用是如何实现的呢？

高可用性（high availability，缩写 HA），指系统无中断地执行其功能的能力，代表系统的可用性程度。高可用性通常通过提高系统的容错能力来实现。

首先，我们来看张图

过程：

• 开始时，处理流程主要是 场景一

AWS RDS MySQL 主从同步延迟总结

参考技术A 最近居然被 MySQL 主从同步的问题坑了, 简直丢尽了老司机的脸, 总结一下.

问题很简单, 一个业务由于 MySQL 主从同步延迟导致读取的数据有问题. 问题解决了, 但如何在 AWS RDS 中获取 MySQL 的延迟信息呢? 非 AWS RDS 的传统 MySQL 中, 可以直接连到 server 通过 SHOW SLAVE STATUS 获取延迟信息.

RDS 呢?

AWS 中大多数(我也不确定是不是所有服务)都接入了 Cloudwatch. Cloudwatch 的好处就是可以作为一个中间层抽象, 将不同系统的数据抽象成一个模型, 统一通过 Cloudwatch API 访问. 就拿主从延迟来说, MySQL/MariaDB 和 PostgeSQL 的计算方法显然是不一样的:

因此, 只要通过 Cloudwatch API 获取 ReplicaLag 这个 metric 的值就可以判断主从同步延迟, 不管是哪种 DB

看上去挺简单的 API, 还是需要"进城手册", 避免挠头:

由于 Cloudwatch 支持的最细颗粒度的 metric 是1分钟, 因此仅仅获取前一分钟的数据可能会有 Cloudwatch 数据还未抓取到的问题.
建议是获取前一段时间(比如10分钟)的数据, 确保前10分钟的 ReplicaLag 都为0(或者小于一个可以接受的值), 则认为现在的状态是满足数据需求的.

MySQL 主从同步从入行就知道是需要重点关注的, 结果还是忽略了一下就掉坑里了. AWS Cloudwatch 也支持根据 ReplicaLag 的值直接告警的, 建议一定要设置一个.