mysql主从延迟怎么办 mysql主从延迟原因( 二 )


我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警,正常的时间是在毫秒级别,一旦落后的时间达到了秒级别就需要告警了 。
解决该问题的方法,除了缩短主从延迟的时间,还有一些其它的方法,基本原理都是尽量不查询从库 。
具体解决方案如下:
在实际应用场景中,对于一些非常核心的场景,比如库存,支付订单等,需要直接查询从库,其它非核心场景,就不要去查主库了 。
两台机器 A 和 B,A 为主库,负责读写,B 为从库,负责读数据 。
如果 A 库发生故障,B 库成为主库负责读写,修复故障后,A 成为从库,主库 B 同步数据到从库 A 。
一台主库多台从库,A 为主库,负责读写,B、C、D为从库 , 负责读数据 。
如果 A 库发生故障,B 库成为主库负责读写,C、D负责读,修复故障后 , A 也成为从库 , 主库 B 同步数据到从库 A 。
mysql无主键无索引表导致同步延迟Mysql主从同步延迟发生
现象mysql主从延迟怎么办:
pos一直保持不变mysql主从延迟怎么办,并且behind一直在增加mysql主从延迟怎么办,
备库执行:
SQL thread State列状态如下:
代表 线程已经从中继日志读取一个事件,可以对事件进行处理了 。
查看binlog:
查看表结构发现没有主键和索引 。
延迟发生原因:
【mysql主从延迟怎么办 mysql主从延迟原因】首先mysql主从是基于行的复制 。
举例解释下什么是基于行的复制,假设主库执行以下sql删除了表A中的100条数据:
这时mysql会把这个SQL按照每条记录,拆分成100条delete SQL在备库上执行,mysql这么做的目的也是最大程度的保证同步数据的可靠性 。
但是可靠性的提升伴随而来的便是日志量的增多,同步过程会占用大量带宽 。
其次,该表即无主键,也没有索引 。
假设还是以上对A表的删除操作,拆成的100条delete SQL传递并且在备库执行 , 因为表即无主键 , 也没有索引,所以每执行一次都要做全表扫描才能定位到要删除的那一条数据,可想而知同步效率会低很多 。
解决方案:
1 表设计时就要有主键mysql主从延迟怎么办;
2 如果延迟已经发生,并且表不是特别大的情况下,在备库上为该表创建索引或是主键 。
AWS RDS MySQL 主从同步延迟总结最近居然被 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 的值直接告警的, 建议一定要设置一个.

推荐阅读