MySQL 主从模式，读写分离的数据延迟，都有什么好的解决方法

mysql5.7 的主从复制是多线程了，阿里在这块也很早就做过优化，如果还是用 5.7 以下的社区版本的话，最简单的方式也就是垂直切分，按业务多分几个集群吧，然后一些读写频繁但对数据一致性要求不高的功能尽量扔 redis 实现

最近居然被 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 的值直接告警的, 建议一定要设置一个.

Mysql主从同步延迟发生 现象： pos一直保持不变，并且behind一直在增加， 备库执行： SQL thread State列状态如下： 代表 线程已经从中继日志读取一个事件，可以对事件进行处理了。 查看binlog： 查看表结构发现没有主键和索引。 延迟发生原因： 首先mysql主从是基于行的复制。 举例解释下什么是基于行的复制，假设主库执行以下sql删除了表A中的100条数据： 这时mysql会把这个SQL按照每条记录，拆分成100条delete SQL在备库上执行，mysql这么做的目的也是最大程度的保证同步数据的可靠性。 但是可靠性的提升伴随而来的便是日志量的增多，同步过程会占用大量带宽。 其次，该表即无主键，也没有索引。 假设还是以上对A表的删除 *** 作，拆成的100条delete SQL传递并且在备库执行，因为表即无主键，也没有索引，所以每执行一次都要做全表扫描才能定位到要删除的那一条数据，可想而知同步效率会低很多。 解决方案： 1 表设计时就要有主键； 2 如果延迟已经发生，并且表不是特别大的情况下，在备库上为该表创建索引或是主键。

---