MySQL主从库的同步机制

MySQL主从库同步机制

文章首发自我的博客：[老白经][http://aminby.net/2013/11/mysql-synchronize-from-master-to-slave-2/]

MySQL主从库的同步

我们设置一个主库(Master)，和一个从库(Slave或Secondary)。从库从主库复制数据内容，目的为灾难备份、读写分离等。

本文主要讲同步机制，至于如何设置MySQL的主库、从库及同步，网上内容很多了，看官只要Google一下“MySQL 主从库 设置”就有了。这里略了。

主从库同步的的基本原理

主库开启binary log，开启后每一次操作更新、修改、删除等都会记录在案，所以从库的同步过程其实就是获得这些过程，然后将现场还原，就达到了数据同步的目的。

旧同步实现机制

为什么讲旧的同步的实现，因为按着开发过程，旧的实现其实就是一个最简原理的表现，虽然考虑不全，都大体方向是对的，所以讲旧的是为了讲新的。

1. Slave开启一个线程，该线程向Master请求从上次同步位置以后的binlog。然后，等待Master返回binlog后，将binlog记录的事件执行一次，并记录该次同步到哪个位置了。
2. Master也很简单，开启一个线程，等待Slave的请求，接到请求后，有了上次同步位置offset，就查询offset后的binlog，返回给Slave。

OK，任务完成了，确实是完成了，只是Slave的线程做的事情有点多，既要请求binlog，又要执行，于是Slave和Master的延时其实是蛮大的，也因为这个蛮大的延时，使得假如在这个延时其间如果Master大量变化后崩溃了，而这些binlogs没来得及同步到Slave，这些变化数据就找不回来了。所以，MySQL开发团队认识到这个问题后，就进行一个改进。

新同步实现机制

原理还是跟旧同步机制一样，只是做了一个改进。这个改进大部分做线程开发的人都懂，把Slave的线程分成两个线程，一个做binlogs的同步(我们称为IO线程)，一个做还原现场的工作(我们称为SQL线程)。如此，Master端的binlogs能以最小的延时，同步到Slave，而Slave这边的现场还原工作就可以慢慢来了，反正binlogs是源材料，即使Master崩溃也丢了binlogs，也可以从Slave里取回去还原。

写在最后

就是这么简单，理解这个实现机制有什么好处？就是方便理解配置MySQL的主库和从库的时候一些配置项以及对MySQL的同步出现问题的时候，知道该往哪个方向去找答案。

但是，不得不说一下，然后新机制貌似解决了同步问题，但是实际上没有，延时还是存在的，只是小了非常多，想想都知道，Slave的IO线程在两次请求之间是有时间距离的，所以这个时间距离内，Master还是有可能变化后崩溃而丢失那部分变化。

所以，事实上要完全避免这个问题，只能用MySQL Cluster(数据库集群)。这是一个大的问题，我们另辟章节来讲。