在我们日常的工作中,处理 MySQL 数据库相关问题时,我相信绝大多数 DBA 处理最棘手的问题就是数据库主从数据不一致的问题。
处理过关于 MySQL 数据库主从数据不一致的朋友一定印象非常深刻,因为稍有不慎就会将造成原有数据的丢失,并且这种丢失是持久性的,也就是说如果我们没有相关备份的话,该数据将会永久丢失,这对于一家互联网公司来说将是非常致命的错误。
那么,我们该如何保证 MySQL 数据库主从数据一致呢?
在介绍这个问题之前,我首先跟大家介绍一下 MySQL 数据库主从复制的原理。
注意:在开启主从复制之前,需要在 Worker 节点上关联 Master 节点,不知道的朋友可以上网查询一下,这里不再赘述。
通常,我们在从库上执行 start slave;,开启主从复制。我们确认是否成功开启主从复制最简单的办法是通过 show slave status; 查看 IO 线程 和 SQL 线程 是否开启。
![](https://i-blog.csdnimg.cn/blog_migrate/85c01acf53c1e875e2326c49b7d13437.jpeg)
下面我们来介绍一下这两个线程背后的逻辑。
![](https://i-blog.csdnimg.cn/blog_migrate/9ad4645b0e7e049dc675a15c02baf3b3.jpeg)
在从库上执行 start slave;,开启主从复制。
从库的 IO 线程开始在读取 Master 节点信息,该信息保存在master.info中。
主库在接收到从库的主从同步请求时,会开启一个 dump 线程,主要用于将 Master 节点的 binlog 日志发送给 Worker 节点。
Worker 节点中的 IO 线程接收 Master 节点发送过来的 binlog 日志的内容。
IO 线程接收到的 binlog 日志内容并不是直接写入到 Worker 节点,而是先保存在缓存之中,这个步骤最主要的原因是为了防止大量数据同时写入中继日志时导致的数据库异常。
Worker 节点在接收完 Master 发送过来的数据时,会回复 Master 节点一个 ACK 信号,这个步骤的目的是告诉 Master 节点数据已接收完毕。