1。复制的常见拓扑复制的架构有以下基本原则：(1)每个slave只能有一个master；(2)每个slave只能有一个UniqueserverID；(3)每个master可以有多个slave；(4)如果设置了log_slave_updates，slave可以成为其他slave的master，从而传播master的更新。MySQL不支持多主复制（MultimasterReplication）——即一个slave可以有多个master。然而，通过一些简单的组合，我们可以构建灵活而强大的复制架构。1.1.单主多从最简单的情况是一个主从组成的复制系统。奴隶之间不相互交流，只能与主人交流。在实际应用场景中，90%以上的MySQL复制都是一个Master复制到一个或多个Slave的架构模型，主要作为读取压力比较大的应用的一种廉价的数据库端扩容方案。因为只要Master和Slave的压力不是太大（尤其是Slave端的压力），异步复制的延迟一般很少。特别是Slave端的replication方式改为两个线程处理，减少了Slave端的延迟问题。好处是对于不需要实时数据的应用，只需要通过廉价的pcservers扩展slave的数量，将读取压力分散到多台slave机器上，就可以分散单个数据库服务器的读取压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中，读压力还是远大于写压力。这在很大程度上解决了很多中小型网站的数据库压力瓶颈问题，甚至一些大型网站也在使用类似的方案来解决数据库瓶颈问题。如下：如果写操作少，读操作频繁，可以采用这种结构。可以将读操作分发给其他slave，从而减轻master的压力。但是当slave增加到一定数量后，slave对master的负载和网络带宽就会成为一个严重的问题。这种结构虽然简单，但足够灵活，可以满足大多数应用需求。一些建议：（1）不同的slave扮演不同的角色（比如使用不同的索引，或者不同的存储引擎）；(2)使用一个slave作为backupmaster，只做复制；(3)使用remoteslave，用于容灾；大家应该比较清楚，一个Master节点可以复制出多个Slave节点。可能有人会疑惑，一个Slave节点可以从多个Master节点复制出来吗？至少目前MySQL做不到，以后会不会支持也不清楚。MySQL不支持一个Slave节点从多个Master节点复制的架构，主要是为了避免冲突，防止多个数据源之间数据冲突，导致最终数据不一致。不过听说有人开发了相关补丁，让MySQL支持一个slave节点从多个master节点作为数据源进行复制。这正是MySQL开源的好处。1.2.Master-MasterinActivemode（主动-主动模式下的Master-Master）Master-Master复制的两台服务器既是另一台服务器的master又是slave。这样，任何一方所做的更改都将通过复制应用到另一方的数据库中。有些读者可能会担心。这样设置复制环境后，会不会造成两个MySQL之间的循环复制呢？其实MySQL本身早就想到了这一点，所以在MySQL的BinaryLog中记录了当前的MySQL。server-id，而这个参数我们在构建MySQLReplication的时候一定要明确指定，Master和Slave的server-id参数值需要不一致才能让MySQLReplication构建成功。一旦有了server-id的值，MySQL就可以很容易地判断出某个变化最初是从哪个MySQLServer产生的，这样就很容易避免出现循环复制的情况。而且，如果我们不开启记录Slave的BinaryLog的选项（--log-slave-update），MySQL根本不会将复制过程中的变化记录到BinaryLog中，更不用担心循环复制上去的可能性。如图：ActiveMaster-Masterreplication有一些特殊的用途。例如，地理上分布的两个部分需要它们自己的数据可写副本。这种结构最大的问题是更新冲突。假设一张表只有一行（一列）数据，其值为1，如果两台服务器同时执行如下语句：在第一台服务器上执行：mysql>UPDATEtblSETcol=col+1;在第二台服务器上执行：mysql>UPDATEtblSETcol=col*2;那么结果如何呢？一台服务器为4，另一台服务器为3，但这不会产生错误。事实上，MySQL并不支持其他一些DBMS所支持的多主复制（MultimasterReplication）。针对这种需求，可以使用MySQLCluster，结合Cluster和Replication构建一个强大的高性能数据库平台。但是，还有其他方法可以模拟这种多主复制。1.3.Master-MasterinActive-PassiveMode（主动-被动模式下的Master-Master）这是master-master结构的改变，避免了M-M的缺点。实际上，它是一个容错和高可用的系统。它的不同之处在于其中一项服务只能执行只读操作。如图：1.4级联复制架构Master-Slaves-Slaves在某些应用场景下，读写压力可能相差很大，其中读压力特别大。一个Master可能需要10个或更多Slave来支撑读条压力。这个时候Master会比较费力，因为只连接的SlaveIO线程比较多，所以当写的压力大一点的时候，Master会因为replication消耗更多的资源，容易造成replication延迟。小时。如何解决这种情况？这时我们可以利用MySQL的功能，在Slave端记录和复制变化的BinaryLog信息，即开启--log-slave-update选项。然后，通过两级（或更多级）复制来减轻Master端因复制而产生的压力。也就是说，我们先通过几台MySQL机器从Master上复制过来，我们称之为顶层Slave集群，然后其他Slave从顶层Slave集群上复制。从一级Slave复制出来的Slave，我称之为二级Slave集群。如果有必要，我们可以继续向下添加更多级别的复制。这样我们就可以很方便地控制每个MySQL挂载的slave数量。我把这种架构称为Master-Slaves-Slaves架构，它是一种多层级联复制架构，轻松解决了Master端因为从属Slave过多而成为瓶颈的风险。下图展示了多层级联复制的Replication架构。当然，如果条件允许，我更倾向于建议大家通过拆分成多个Replication集群来解决上述瓶颈问题。毕竟Slave并没有减少写入量，所有的Slave实际上还是应用了所有的数据变更操作，并没有减少任何写入IO。反之，slave越多，整个集群的写IO总量就会越大。我们没有很明显的感觉，但是因为是分布在多台机器上，所以不容易表现出来。另外，如果增加复制的级联层级，同样的变更需要经过更多的MySQL才能传输到顶层的Slave，这也可能带来延迟更长的风险。而如果我们通过拆分集群来解决，可能会好很多。当然，拆分集群也需要更复杂的技术和更复杂的应用系统架构。1.5.带从服务器的Master-Master结构（Master-MasterwithSlaves）这种结构的优点是它提供了冗余。在异地分布式复制结构中，不存在单节点故障问题，也可以将读密集型请求放在slave上。级联复制在一定程度上确实解决了master因挂载的slave过多而成为瓶颈的问题，但无法解决手动维护后重新建立复制以及需要切换异常的问题。这自然导致了结合DualMaster和级联复制的Replication架构。我称之为主-主-从架构。一个单独的Master设置为备Master，然后从备Master复制到一个Slave集群。这种DualMaster和级联复制架构结合的最大好处就是可以避免master主master的写操作受到slave集群复制的影响，同时基本不需要切换的时候mastermaster需要切换。会出现Replication被重建的情况。但是这种架构也有一个缺点，就是备Master可能会成为瓶颈，因为如果后续的Slave集群比较大，备Master可能会因为SlaveIO线程请求过多而成为瓶颈。当然，当standbyMaster不提供任何读服务时，出现瓶颈的可能性也不是特别高。如果出现瓶颈，可以在备用Master后面再次进行级联复制，搭建多层Slave集群。当然，级联复制的层级越多，slave集群可能出现的数据延迟就越明显，所以在考虑使用多层级联复制之前，还需要评估数据延迟对应用系统的影响。
