Mysql Dual Master双主复制架构

常用的复制方式是一主一从的基本架构，但有时可能还会需要在一些特定的场景下进行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环境，并不是为了让两端都提供写的服务。在正常情况下，只会将其中一端开启写服务，另外一端仅仅提供读服务，或者完全不提供任何服务，只是作为一个备用的机器存在

为什么一般都只开启其中的一端来提供写服务呢？主要还是为了避免数据的冲突，防止造成数据的不一致性