一文读懂MySQL复制机制

背景介绍

复制，就是对数据的完整拷贝，说到为何要复制，首先能想到的是怕数据意外丢失，使得用户蒙受损失。

当完成了数据复制以后，会发现它的优点不止这一点，假如一台机器宕机了，能够启用备份在另外一台机器的数据。毕竟宕机的几率很小，闲暇时间还可让备份机器分担主机器的流量压力。除此以外，当要升级数据库版本时，能够在不中止用户服务的状况下优先升级备用机器，待观测其可用稳定时再将主数据库升级。

可是，也不能总让DBA手动拷贝来完成复制，万一在DBA蹲坑的时候宕机了，在蹲坑期间产生的数据因为没有及时备份，会致使备用数据库的数据缺失，因此仍是要设计一套能够自动复制的机制。

设计复制机制

咱们暂定被复制的数据库为主库，粘贴出来的为从库，要实现主库到从库的复制，看起来很是简单，只需一个计划任务，定时将主库数据文件复制一份，并传输到从库所在服务器。

但毕竟定时任务不是实时的，万一主库在上次复制的十分钟后发生了故障，被激活的从库用的是最近一次复制的数据，因此会缺失十分钟的数据，后果不堪设想。

仍是要实时复制，那能够这样，主库将每次执行完的语句实时发给从库，让从库立刻执行，就能保证两边数据一致了。

不太好的是，主库是实时发送数据给从库的，须要等从库执行完毕才能处理下一条语句，严重占用了主库的执行时间，若是从库过多，主库就废了。

还得改为异步才能节省主库的时间，能够将主库执行完的语句存到文件里，让从库来取，这样主库就不用等待从库了。既然是写到文件，速度是很快的，主库彻底能够在执行前就将语句写到文件中，达到更高的同步效率。

上述有些问题，从库没法作到跑去主库取数据，只能起一个线程先与主库创建链接，并向主库索要数据，而后主库也起一个线程读取文件内容，并推给从库线程，从库收到语句后就能够立刻执行了。

这样效率仍是很低，主库的线程要等从库收到语句并执行完毕才能推下一条，若是有多个从库，主库就要开启多个线程长期与各个从库保持通讯，占用主库服务器资源，不如从库也建立个文件临时保存主库发来的语句，先存起来再慢慢执行，主库压力小了，从库也放心。

如今从库有了本身的文件作中继，就不用着急了，从库能够再起一个线程，慢慢执行中继文件中的语句，执行完毕以后原文件没有价值了，就能够清理掉，省得占用服务器资源。

到目前为止，最基本的复制机制就设计完了，这种由主库到从库的复制方式就是典型的主从架构，在此基础上能够进行演化，好比从库有不少，主库要为每一个从库推送数据，主库的压力会随之增大，又由于主库的职责不只仅是同步数据，还要忙着读写数据，因此同步数据的事能够找人代替，好比在主库与从库之间再创建一个主库，新创建的主库惟一的职责就是同步数据给从库，这样真正的主库就只须要推送一次数据给新建的主库，其他时间就能够安心读写数据了。

这种演化而来的复制模式叫作多级复制架构，本文到此结束，上述就是三种复制架构中的其中两种，除此以外还有一个“主主”架构，在这里就再也不多说了，感兴趣的能够自行了解或关注咱们后续的文章。

若是你愿意，让我来帮你关注不知道又想知道却想不到的知识。