摘要：备库如果长时间没有收到从主库过来的变更，它会每隔一段时间重连主库。这就是为什么在我们模拟的场景下，一个小时后，备库才会重连主库，继续同步数据变更的原因。
1、首先讨论一下哪些现象造成：IO thread和SQL thread的双Yes假象的问题
① 正常shutdown 或者 kill mysqld
结果状态单：
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Last_IO_Errno: 2003
② kill -9 mysqld 或者 reboot 服务器
结果状态:有可能同①，也有可能是双Yes（我自己测试的是同①结果，看别人测的有的是双yes）
③ 临时断开主库的网络，并 kill 掉主库 MySQL 的 binlog dump 线程
结果状态单：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
说明：
网络恢复之后，binlog dump线程已不存在；
主库有新的写入，从库无法同步，但是I/O线程和SQL线程都是YES，SBM也没有延迟
主库上记录二进制日志，也就是binlog日志。
备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转存（Binglog Dump）线程，这个转存线程会读取主库上的二进制日志中事件，并发送给从库的I/O线程；如果主库没有更新信息将进入休眠。
备库的SQL线程执行最后一步，该线程从中继日志中读取事件并在备库执行，从而实现备库数据的更新。
首先， MySQL 的复制是“推”的，而不是“拉”的。“拉”是指 MySQL 的备库不断的循环询问主库是否有数据更新，这种方式资源消耗多，并且效率低。“推”是指 MySQL 的主库在自己有数据更新的时候推送这个变更给备库，这种方式只有在数据有变更的时候才会发生交互，资源消耗少。如果你是程序员出身，你一定会选择“推”的方式。
那么 MySQL 具体是怎么“推”的列，实际上备库在向主库申请数据变更记录的时候，需要指定从主库Binlog 的哪个文件 ( MASTER_LOG_FILE ) 的具体多少个字节偏移位置 ( MASTER_LOG_POS ) 。对应的，主库会启动一个 Binlog dump 的线程，将变更的记录从这个位置开始一条一条的发给备库。备库一直监听主库过来的变更，接收到一条，才会在本地应用这个数据变更。
从上面的分析，我们可以大致猜到为什么 show slave status 显示一切正常，但是实际上主库的变更都无法同步到备库上来：
出现问题的时候， Binlog dump 程序被我们 kill 掉了。作为监听的一方，备库一直没有收到任何变更，它会认为主库上长时间没有任何变更，导致没有变更数据推送过来。备库是无法判断主库上对应的Binlog dump 线程到底是意外终止了，还是长时间没有任何数据变更的。所以，对这两种情况来说，备库都显示为正常。
当然， MySQL 会尽量避免这种情况。比如：
a.在 Binlog dump 被 kill 掉时通知备库 线程 被 kill 掉了。所以我们重现时需要保证这个通知发送不到备库，也就是说该问题重现的关键在于 Binlog dump 被 kill 的消息由于网络堵塞或者其他原因无法发送到备库。
b.备库如果长时间没有收到从主库过来的变更，它会每隔一段时间重连主库。
基于上面的分析，我们知道 MySQL 在这种情况下确实无法避免，那么我们可以有哪些办法可以避开：
（1） 被动处理：修改延迟的监控方法，发现问题及时处理。
（2） 主动预防：正确设置 --master-retry-count ， --master-connect-retry ， --slave-net-timeout 复制重试参数。
MySQL 的延迟监控大部分直接采集 show slave status 中的 Seconds_Behind_Master。这种情况下，Seconds_Behind_Master 就无法用来真实的衡量主备之间的复制延迟了。我们建议通过在主库轮询插入时间信息，并通过复制到备库的时间差来获得主备延迟的方案。 Percona 提供了一种类似的方案 pt-heartbeat 。
发现这个问题以后，我们只需要 stop slave; start slave; 重启复制就能解决这个问题。
MySQL 可以指定三个参数，用于复制线程重连主库： --master-retry-count ， --master-connect-retry ， --slave-net-timeout 。
其中 master-connect-retry 和 master-retry-count 需要在 Change Master 搭建主备复制时指定，而 slave-net-timeout 是一个全局变量，可以在 MySQL 运行时在线设置。
具体的重试策略为：
备库过了 slave-net-timeout 秒还没有收到主库来的数据，它就会开始第一次重试。然后每过 master-connect-retry 秒，备库会再次尝试重连主库。直到重试了 master-retry-count 次，它才会放弃重试。如果重试的过程中，连上了主库，那么它认为当前主库是好的，又会开始 slave-net-timeout 秒的等待。
slave-net-timeout 的默认值是 3600 秒，
master-connect-retry 默认为 60 秒，
master-retry-count 默认为 86400 次。
也就是说，如果主库一个小时都没有任何数据变更发送过来，备库才会尝试重连主库。这就是为什么在我们模拟的场景下，一个小时后，备库才会重连主库，继续同步数据变更的原因。
这样的话，如果你的主库上变更比较频繁，可以考虑将 slave-net-timeout 设置的小一点，避免主库Binlog dump 线程 终止了，无法将最新的更新推送过来。
当然 slave-net-timeout 设置的过小也有问题，这样会导致如果主库的变更确实比较少的时候，备库频繁的重新连接主库，造成资源浪费。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/48723.html
摘要：四解决方法将调大，设置为小时五错误的做法看到二出现的现象后，做了如下操作此时查看的状态如下无法找到的位置点，会从最开始的进行读取，的日志如下此时需要先关闭，再设置点，最后再开启，具体如下再次查看的状态，可以看到状态正常 说明： 系统：centos7 主库 M：192.168.16.12：3306 从库 S：192.168.16.15：3306 主从复制：传统复制 一、场景 M、S...
摘要：在事件写入二进制日志完成后，通知存储引擎提交事务。线程从中继日志读取事件，并重放其中的事件而更新的数据，使其与中的数据一致。在模式下，复制的是里的，在模式下是主库事件执行完成后影响的行精确复制。主从切换后，从库事件状态会变成。 1. 说明 1.1 xtrabackup mysqldump对于导出10G以下的数据库或几个表，还是适用的，而且更快捷。一旦数据量达到100-500G，无论是对...
摘要：当然我们在实际运维过程中都应针对不同的业务需求分析和选择合适的备份恢复方案，这篇文章就是针对多实例且一个实例对应多个的情况，实现在线不停机不锁表的主从同步，日后再继续更新分享基于的其它实用技能。 showImg(//i.v2ex.co/02ftb7pa.jpeg); 前言 Percona XtraBackup可以说是一个相对完美的免费开源数据备份工具，支持在线无锁表同步复制和可并行...
摘要：数据库主从同步延迟解决方案。数据库主从同步延迟解决方案答最简单的减少同步延时的方案就是在架构上做优化，尽量让主库的快速执行。原理和丁奇的类似，丁奇的是以表做多线程，使用的是以数据库为单位做多线程，不同的库可以使用不同的复制线程。 MySQL的主从同步是一个很成熟的架构，优点为：①在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力;②在从主服务器进行备份，避免备份期间影响...
摘要：可以帮助选择更好的索引和写出更优化的查询语句查询到会执行多少时间并看出使用量执行过程中花多少时间等等本章主要是对做简单的概述，用来对某一条语句进行性能分析。但是在之后，信息将逐渐被废弃，推荐使用。 前言 在我们做mysql性能分析的时候，最常用的有三种方式： （1）慢查询 （分析出现出问题的sql） （2）Explain （显示了mysql如何使用索引来处理select语句以及连接...
阅读 3270·2021-11-18 10:02
阅读 2959·2019-08-29 18:34
阅读 3271·2019-08-29 17:00
阅读 294·2019-08-29 12:35
阅读 593·2019-08-28 18:22
阅读 1532·2019-08-26 13:58
阅读 1524·2019-08-26 10:39
阅读 2570·2019-08-26 10:11
