当主库I/O负载很大或是网络阻塞
io_thread不能及时复制binlog(没有中断 , 也在复制) , 而sql_thread一直都能跟上io_thread的脚本 , 这时Seconds_Behind_Master的值是0 ,
也就是我们认为的无延时 , 但是 , 实际上不是 , 你懂得 。
这也就是为什么大家要批判用这个参数来监控数据库是否发生延时不准的原因 , 但是这个值并不是总是不准 ,
如果当io_thread与master网络很好的情况下 , 那么该值也是很有价值的 。’‘之前 , 提到Seconds_Behind_Master这个参数会有负值出现 , 我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到的ts差值 ,
前者始终是大于后者的 , 唯一的肯能就是某个event的ts发生了错误 , 比之前的小了 , 那么当这种情况发生时 , 负值出现就成为可能 。
3.2 方法2.
mk-heartbeat:Maatkit万能工具包中的一个工具 , 被认为可以准确判断复制延时的方法 。
mk-heartbeat的实现也是借助timestmp的比较实现的 , 它首先需要保证主从服务器必须要保持一致 , 通过与相同的一个NTP server同步时钟 。它需要在主库上创建一个heartbeat的表 , 里面至少有id与ts两个字段 , id为server_id , ts就是当前的时间戳now() , 该结构也会被复制到从库上 , 表建好以后 , 会在主库上以后台进程的模式去执行一行更新操作的命令 , 定期去向表中的插入数据 , 这个周期默认为1秒 , 同时从库也会在后台执行一个监控命令 , 与主库保持一致的周期去比较 , 复制过来记录的ts值与主库上的同一条ts值 , 差值为0表示无延时 , 差值越大表示延时的秒数越多 。我们都知道复制是异步的ts不肯完全一致 , 所以该工具允许半秒的差距 , 在这之内的差异都可忽略认为无延时 。这个工具就是通过实打实的复制 , 巧妙的借用timestamp来检查延时 。
获取资料:
最后给大家分享一份学习资料 , 里面包括:(BATJ面试资料、高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码 , MyBatis , Netty , redis , Kafka , Mysql , Zookeeper , Tomcat , Docker , Dubbo , Nginx等多个知识点的架构资料)和JAVA进阶学习路线图 。
【MySQL主从不一致情形与解决方法】
推荐阅读
- MySQL INSERT 有哪4种形态?
- MYSQL主主模式 LNMP 独立部署配置指导书
- MySQL的隐式转化
- MySQL的备份与恢复
- MySQL索引怎么用?究竟能有多快?看完这篇你就懂了
- 多场景下MySQL临时表有什么用?
- MySQL两地三中心方案初步设计
- 100% 展示 MySQL 语句执行的神器-Optimizer Trace
- MySQL,合理的使用索引结构和查询
- MySQL进阶篇 | 合理的使用索引结构和查询
