mysql主从延迟怎么办 mysql主从延迟原因

MySQL 主从,5 分钟带你掌握MySQL 主从一直是面试常客,里面mysql主从延迟怎么办的知识点虽然基础 , 但是能回答全的同学不多 。
比如楼哥之前面试小米,就被问到过主从复制的原理 , 以及主从延迟的解决方案,因为回答的非常不错,给面试官留下非常好的印象 。你之前面试,有遇到过哪些 MySQL 主从的问题呢?
所谓 MySQL 主从,就是建立两个完全一样的数据库,一个是主库 , 一个是从库,主库对外提供读写的操作 , 从库对外提供读的操作,下面是一主一从模式:
对于数据库单机部署,在 4 核 8G 的机器上运行 MySQL 5.7 时,大概可以支撑 500 的 TPS 和 10000 的 QPS,当遇到一些活动时,查询流量骤然,就需要进行主从分离 。
大部分系统的访问模型是读多写少,读写请求量的差距可能达到几个数量级,所以我们可以通过一主多从的方式,主库只负责写入和部分核心逻辑的查询,多个从库只负责查询 , 提升查询性能,降低主库压力 。
MySQL 主从还能做到服务高可用,当主库宕机时,从库可以切成主库,保证服务的高可用,然后主库也可以做数据的容灾备份 。
整体场景总结如下:
MySQL 的主从复制是依赖于 binlog 的,也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件 。
主从复制就是将 binlog 中的数据从主库传输到从库上,一般这个过程是异步的 , 即主库上的操作不会等待 binlog 同步的完成 。
详细流程如下:
当主库和从库数据同步时,突然中断怎么办?因为主库与从库之间维持mysql主从延迟怎么办了一个长链接,主库内部有一个线程 , 专门服务于从库的这个长链接的 。
对于下面的情况,假如主库执行如下 SQL,其中 a 和 create_time 都是索引:
我们知道,数据选择mysql主从延迟怎么办了 a 索引和选择 create_time 索引 , 最后 limit 1 出来的数据一般是不一样的 。
所以就会存在这种情况:在 binlog = statement 格式时,主库在执行这条 SQL 时,使用的是索引 a,而从库在执行这条 SQL 时,使用了索引 create_time , 最后主从数据不一致了 。
那么我们改如何解决呢?
可以把 binlog 格式修改为 row,row 格式的 binlog 日志记录的不是 SQL 原文,而是两个 event:Table_map 和 Delete_rows 。
Table_map event 说明要操作的表,Delete_rows event用于定义要删除的行为,记录删除的具体行数 。row 格式的 binlog 记录的就是要删除的主键 ID 信息 , 因此不会出现主从不一致的问题 。
但是如果 SQL 删除 10 万行数据 , 使用 row 格式就会很占空间的,10 万条数据都在 binlog 里面 , 写 binlog 的时候也很耗 IO 。但是 statement 格式的 binlog 可能会导致数据不一致 。
设计 MySQL 的大叔想了一个折中的方案,mixed 格式的 binlog,其实就是 row 和 statement 格式混合使用,当 MySQL 判断可能数据不一致时 , 就用 row 格式,否则使用就用 statement 格式 。
有时候我们遇到从数据库中获取不到信息的诡异问题时,会纠结于代码中是否有一些逻辑会把之前写入的内容删除 , 但是你又会发现,过了一段时间再去查询时又可以读到数据了 , 这基本上就是主从延迟在作怪 。
主从延迟,其实就是“从库回放” 完成的时间,与 “主库写 binlog” 完成时间的差值,会导致从库查询的数据,和主库的不一致。
谈到 MySQL 数据库主从同步延迟原理 , 得从 MySQL 的主从复制原理说起:
总结一下主从延迟的主要原因:主从延迟主要是出现在 “relay log 回放” 这一步,当主库的 TPS 并发较高,产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围,那么延时就产生了,当然还有就是可能与从库的大型 query 语句产生了锁等待 。

推荐阅读