mysql同步更新的问题

mysql同步更新的问题,第1张

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


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5902178.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-07
下一篇 2023-03-07

发表评论

登录后才能评论

评论列表(0条)

保存