一文读懂MySQL复制机制
收藏


背景介绍

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

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

但是,也不能总让DBA手动拷贝来完成复制,万一在DBA蹲坑的时候宕机了,在蹲坑期间产生的数据由于没有及时备份,会导致备用数据库的数据缺失,所以还是要设计一套可以自动复制的机制。

设计复制机制

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

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

还是要实时复制,那可以这样,主库将每次执行完的语句实时发给从库,让从库马上执行,就能保证两边数据一致了。

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

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

上述有些问题,从库无法做到跑去主库取数据,只能起一个线程先与主库建立连接,并向主库索要数据,然后主库也起一个线程读取文件内容,并推给从库线程,从库收到语句后就可以马上执行了。

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

现在从库有了自己的文件做中继,就不用着急了,从库可以再起一个线程,慢慢执行中继文件中的语句,执行完毕之后原文件没有价值了,就可以清理掉,免得占用服务器资源。

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

这种演化而来的复制模式叫做多级复制架构,本文到此结束,上述就是三种复制架构中的其中两种,除此之外还有一个“主主”架构,在这里就不再多说了,感兴趣的可以自行了解。








官方公众号