前言
作为一名DBA，在工作中会经常遇到一些MySQL主从同步延迟的问题，这些同步慢的问题，其实原因非常多，可能是因为主从的网络问题导致，可能是因为网络带宽问题导致，可能是因为大事务导致，也可能是因为单线程复制导致的延迟。
今天遇到一个问题，Mysql持续报错，主从同步延时数过大或错误。所以这篇文章给大家分享下主从同步的机制原理以及问题排查思路。
故障表现
最直观的表现为：
连续查询，大部分时间该属性值=0，偶发性出现Null或者79等延时值。导致观察主从同步延时的监控持续报警。
故障原因及解决方案
多台备机的server-id一致，导致主机无法长时间同某一台备机连接，进而无法正常同步。
修改server-id后，重启数据库恢复。
主从同步机制
MySQL的主从同步，又称为复制（replication），是一种内置的高可用高性能集群解决方案，主要功能有：
主从同步分为3步：
主从同步是一个异步实时的同步，会实时的传输，但存在执行上的延时，如果主服务器压力很大，延时也会相应扩大。
通过上面的图，可以看到一共需要3个线程：
查看MySQL线程
我们可以使用show full processlist;命令来查看MySQL的状态：
主机的状态：
备机的状态：
可以看到，我的集群架构为1台主机、4台备机，所以在主机中有4个同步线程（已经发送所有的binlog数据到备机，等待binlog日志更新），1个查看命令线程（show full processlist）。在备机中有1个查看命令线程，1个I/O线程（等待主机发送同步数据事件），1个SQL线程（已经读取了所有中继日志，等待I/O线程来更新它）。
查看同步状态
因为主从同步是异步实时的，也就是会存在延时的情况，我们可以通过show slave status;来查看备机上的同步延时：
在主从同步中我们需要关注的一些属性，已经给大家标红了：
同样可以通过show master status;命令来查看主服务器的运行状态：
正常运行的主从同步状态：
Slave_IO_Running: YES
Slave_SQL_Running: YES
Seconds_Behind_Master: 0
问题排查
在理解了主从同步的机制后，再来看今天遇到的问题，通过查看备机状态，我们观察在三种状态下的几个关键属性值：
通过MySQL主从复制线程状态转变，我们可以看到三种状态的不同含义：
在这里，我们可以猜测，由于某些原因，从服务器不断的和主服务器进行断开并尝试重连，重连成功后又再次断开。
我们再看看主机的运行情况：
发现问题出在10.144.63.*和10.144.68.*两台机器上，我们查看其中一台的错误日志：
190214 11:33:20 [Note] Slave: received end packet from server, apparent master shutdown:
190214 11:33:20 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.005682' at postion 13628070
拿到关键字Slave: received end packet from server, apparent master shutdown: Google搜索一下，在文章Confusing MySQL Replication Error Message中可以看到原因为两台备机的server-id重复。
One day it happen to me, and took me almost an hour to find that out.
Moving foward I always use a base my.cnf to I copy to any other server and the first thing is to increase the server-id.
Could MySQL just use the servername intead of a numeric value?
问题修复
定位了问题，我们确认下是否重复，发现两台备机的该字段确实相同：
更改一个其他不同的数字，保存，重启MySQL进程，报警恢复。
总结
最终来看，这个问题的解决非常简单，但从刚开始的迷茫到最后的思路清晰，都是我们排查问题所常见的，这篇文章的主要收获是让你明白主从同步的机制和追查问题的思路，希望下次我们都能很快的解决主从同步带给我们的问题。
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对VeVb武林网的支持。
参考资料
新闻热点
疑难解答
