mysql同步更新的问题

1 同步，不管是主从、还是主主，增、删、改都能同步的。如果这些都做不到，同步估计也就没什么用了。

2 基于主键的同步问题，只要保证同步前表的定义数据一致，任何 *** 作都能同步。因为表的定义有个 AUTO_INCREMENT=n 的表属性的问题，通过 show create table tbname可以查看。

主主复制情况下，同时在两端insert的话会造成相同id的各自的记录，因此这也是不推荐主主复制的两端同时都连接实时应用程序，而是把其中一个作为随时的切换备库。

至于更新是不存在问题的。

当然，任何事都有例外，还是有些需注意的问题，请参考手册上对 binlog_format (日志模式)的说明。

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

---