有些时候，简单地从一个MySQL复制到另一个MySQL的基本Replication架构，可能还会需要在一些特定的场景下进行Master的切换。如在Master端需要进行一些特别的维护操作时，可能需要停止MySQL的服务。这时候，为了尽可能减少应用系统写服务的停机时间，最佳的做法就是将slave节点切换成Master来提供写入的服务。

    但是这样一来，原来Master节点的数据就会和实际的数据不一致了。当原Master启动可以正常提供服务的时候，由于数据不一致，不得不通过反转原Master-slave关系，重新搭建Replication环境，并以Master作为slave来对外提供读服务。重新搭建Replication环境会给我们带来很多额外的工作量，如果没有合适的备份，可能还会让Replication的搭建过程非常麻烦。

    为了解决这个问题，可以通过搭建Dual Master环境来处理。何谓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最初产生的，所以就很容易避免出现循环复制的情况。而且，如果不打开记录的slave的binary log的选项时，MySQL根本就不会记录复制过程中的变更到binary log中，就更不用担心可能会出现循环复制的情形了。

    通过Dual Master复制架构，能够避免正常的常规维护操作需要的停机所带来的重新搭建Replication环境的操作，因为任何一端都记录了自己当前复制到对方的什么位置了，在系统搭建之后，它就会自动从之前的位置开始重新复制，不需要人为地干预，大大节省了维护成本。

    不仅如此，Dual Master复制架构和一些第三方的HA管理软件结合，还可以在当前使用的 Master出现异常无法提供服务之后，非常迅速地自动切换另外一端来提供相应的服务，减少异常情况下带来的停机时间，也不需要人工干预。

    当然，搭建一个Dual Master环境，并不是为了让两端都提供写的服务。在正常情况下，我们只会将其中一端开启写服务，另外一端仅仅提供读服务，或者完全不提供任何服务，只是作为一个备用的机器存在。为什么一般都只开启其中的一端来提供写服务呢？主要还是为了避免数据的冲突，防止造成数据的不一致性。因为即使在两边执行的修改有先后顺序，但由于Replication是异步的实现机制，同样会导致晚做的修改也可能会被早做的修改所覆盖。

    当然，也可以通过特殊的约定，让某些表的写操作全部在一端，而另外一些表的写操作全部在另一端，保证两端不会操作相同的表，这样就能避免上面问题的发生。