常用的复制方式是一主一从的基本架构,但有时可能还会需要在一些特定的场景下进行Master的切换
如在Master端进行一些维护操作时,可能要停止MySQL的服务。这时候,为了尽可能减少停机时间,最佳做法就是将Slave节点切换成Master来提供写入的服务
但这样一来,原来Master节点的数据就会和实际的数据不一致了。当原Master启动可以正常提供服务的时候,由于数据不一致,不得不通过反转原Master - Slave关系,重新搭建Replication环境,并以原Master作为Slave来对外提供读服务。重新搭建Replication环境会给我们带来很多额外的工作量,如果没有合适的备份,可能还会让Replication的搭建过程非常麻烦
为了解决这个问题,可以通过搭建Dual Master环境来处理,就是两个MySQL Server互相将对方作为自己的Master,自己作为对方的Slave来进行复制。这样,任何一方所做的变更,都会通过复制应用到另外一方的数据库中
这样搭建复制环境之后,会不会造成两台MySQL之间的循环复制?
MySQL早就想到了这一点,所以在MySQL的Binary Log中记录了当前MySQL的server-id,而且这个参数也是搭建MySQL Replication的时候必须明确指定的,只有Master和Slave的server-id参数值不一致时MySQL Replication才能搭建成功。一旦有了server-id的值,MySQL就很容易判断某个变更是从哪一个MySQL Server最初产生的,所以就很容易避免出现循环复制的情况
通过Dual Master复制架构,能够避免因为正常维护所带来的重新搭建Replication环境的操作,因为任何一端都记录了自己当前复制到对方的什么位置了,在系统搭建之后,它就会自动从之前的位置开始重新复制,不需要人为地干预,大大节省了维护成本
不仅如此,Dual Master复制架构和一些第三方的HA管理软件结合,还可以在当前使用的Master出现异常无法提供服务之后,非常迅速地自动切换另外一端来提供相应的服务,减少异常情况下带来的停机时间,也不需要人工干预
当然,搭建一个Dual Master环境,并不是为了让两端都提供写的服务。在正常情况下,只会将其中一端开启写服务,另外一端仅仅提供读服务,或者完全不提供任何服务,只是作为一个备用的机器存在
为什么一般都只开启其中的一端来提供写服务呢?主要还是为了避免数据的冲突,防止造成数据的不一致性