1 复制概述
Mysql内建的复制功能是构建⼤型，⾼性能应⽤程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某⼀台主机的 数据复制到其它主机（slaves）上，并重新执⾏⼀遍来实现的。复制过程中⼀个服务器充当主服务器，⽽⼀个或多个其它服务器充当从服务器。主服务器将更 新写⼊⼆进制⽇志⽂件，并维护⽂件的⼀个索引以跟踪⽇志循环。这些⽇志可以记录发送到从服务器的更新。当⼀个从服务器连接主服务器时，它通知主服务器从服 务器在⽇志中读取的最后⼀次成功更新的位置。从服务器接收从那时起发⽣的任何更新，然后封锁并等待主服务器通知新的更新。
请注意当你进⾏复制时，所有对复制中的表的更新必须在主服务器上进⾏。否则，你必须要⼩⼼，以避免⽤户对主服务器上的表进⾏的更新与对从服务器上的表所进⾏的更新之间的冲突。
1.1 mysql⽀持的复制类型：
（１）：基于语句的复制： 在主服务器上执⾏的SQL语句，在从服务器上执⾏同样的语句。MySQL默认采⽤基于语句的复制，效率⽐较⾼。⼀旦发现没法精确复制时， 会⾃动选着基于⾏的复制。
（２）：基于⾏的复制：把改变的内容复制过去，⽽不是把命令在从服务器上执⾏⼀遍. 从mysql5.0开始⽀持
（３）：混合类型的复制: 默认采⽤基于语句的复制，⼀旦发现基于语句的⽆法精确的复制时，就会采⽤基于⾏的复制。
1.2 . 复制解决的问题
MySQL复制技术有以下⼀些特点： (1) 数据分布 (Data distribution ) (2) 负载平衡(load balancing) (3) 备份(Backups)
(4) ⾼可⽤性和容错⾏ High availability and failover
1.3 复制如何⼯作
整体上来说，复制有3个步骤：
(1) master将改变记录到⼆进制⽇志(binary log)中（这些记录叫做⼆进制⽇志事件，binary log events）； (2) slave将master的binary log events拷贝到它的中继⽇志(relay log)； (3) slave重做中继⽇志中的事件，将改变反映它⾃⼰的数据。下图描述了复制的过程：
该过程的第⼀部分就是master记录⼆进制⽇志。在每个事务更新数据完成之前，master在⼆⽇志记录这些改变。MySQL将事务串⾏的写⼊⼆进制⽇ 志，即使事务中的语句都是交叉执⾏的。在事件写⼊⼆进制⽇志完成后，master通知存储引擎提交事务。
下⼀步就是slave将master的binary log拷贝到它⾃⼰的中继⽇志。⾸先，slave开始⼀个⼯作线程——I/O线程。I/O线程在master上打开⼀个普通的连接，然后开始binlog dump process。Binlog dump process从master的⼆进制⽇志中读取事件，如果已经跟上master，它会睡眠并等待master产⽣新的事件。I/O线程将这些事件写⼊中 继⽇志。
SQL slave thread（SQL从线程）处理该过程的最后⼀步。SQL线程从中继⽇志读取事件，并重放其中的事件⽽更新slave的数据，使其与master中的数 据⼀致。只要该线程与I/O线程保持⼀致，中继⽇志通常会位于OS的缓存中，所以中继⽇志的开销很⼩。
此外，在master中也有⼀个⼯作线程：和其它MySQL的连接⼀样，slave在master中打开⼀个连接也会使得master开始⼀个线程。复制过程有⼀个很重要的限制——复制在slave上是串⾏化的，也就是说master上的并⾏更新操作不能在slave上并⾏操作。
2 .复制配置
有两台MySQL数据库服 务器Master和slave，Master为主服务器，slave为从服务器，初始状态时，Master和slave中的数据信息相同，当Master 中的数据发⽣变化时，slave也跟着发⽣相应的变化，使得master和slave的数据信息同步，达到备份的⽬的。要点：
负责在主、从服务器传输各种修改动作的媒介是主服务器的⼆进制变更⽇志，这个⽇志记载着需要传输给从服务器的各种修改动作。因此，主服务器必须激活⼆进制⽇志功能。从服务器必须具备⾜以让它连接主服务器并请求主服务器把⼆进制变更⽇志传输给它的权限。 环境：
Master和slave的MySQL数据库版本同为5.0.18操作系统：unbuntu 11.10IP地址：10.100.0.100
2.1、创建复制帐号
1、在Master的数据库中建⽴⼀个备份帐户：每个slave使⽤标准的MySQL⽤户名和密码连接master。进⾏复制操作的⽤户会授予REPLICATION SLAVE权限。⽤户名的密码都会存储在⽂本⽂件master.info中命令如下：
mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@’10.100.0.200’ IDENTIFIED BY ‘1234’;
建⽴⼀个帐户backup，并且只能允许从10.100.0.200这个地址上来登陆，密码是1234。
(如果因为mysql版本新旧密码算法不同，可以设置：set password for 'backup'@'10.100.0.200'=old_password('1234')）
2.2、拷贝数据
（假如是你完全新安装mysql主从服务器，这个⼀步就不需要。因为新安装的master和slave有相同的数据）
关停Master服务器，将Master中的数据拷贝到B服务器中，使得Master和slave中的数据同步，并且确保在全部设置操作结束前，禁⽌在Master和slave服务器中进⾏写操作，使得两数据库中的数据⼀定要相同！
2.3、配置master
接下来对master进⾏配置，包括打开⼆进制⽇志，指定唯⼀的servr ID。例如，在配置⽂件加⼊如下值：server-id=1
log-bin=mysql-bin
server-id：为主服务器A的ID值log-bin：⼆进制变更⽇值
重启master，运⾏SHOW MASTER STATUS，输出如下：
2.4、配置slave
Slave的配置与master类似，你同样需要重启slave的MySQL。如下：log_bin = mysql-binserver_id = 2
relay_log = mysql-relay-binlog_slave_updates = 1read_only = 1
server_id 是必须的，⽽且唯⼀。slave没有必要开启⼆进制⽇志，但是在⼀些情况下，必须设置，例如，如果slave为其它slave的master，必须设置 bin_log。在这⾥，我们开启了⼆进制⽇志，⽽且显⽰的命名(默认名称为hostname，但是，如果hostname改变则会出现问题)。relay_log配置中继⽇志，log_slave_updates表⽰slave将复制事件写进⾃⼰的⼆进制⽇志(后⾯会看到它的⽤处)。
有 些⼈开启了slave的⼆进制⽇志，却没有设置log_slave_updates，然后查看slave的数据是否改变，这是⼀种错误的配置。所以，尽量 使⽤read_only，它防⽌改变数据(除了特殊的线程)。但是，read_only并是很实⽤，特别是那些需要在slave上创建表的应⽤。
2.5、启动slave
接 下来就是让slave连接master，并开始重做master⼆进制⽇志中的事件。你不应该⽤配置⽂件进⾏该操作，⽽应该使⽤CHANGE
MASTER TO语句，该语句可以完全取代对配置⽂件的修改，⽽且它可以为slave指定不同的master，⽽不需要停⽌服务器。如下：mysql> CHANGE MASTER TO MASTER_HOST='server1', -> MASTER_USER='repl',
-> MASTER_PASSWORD='p4ssword', -> MASTER_LOG_FILE='mysql-bin.000001', -> MASTER_LOG_POS=0;
MASTER_LOG_POS的值为0，因为它是⽇志的开始位置。你可以⽤SHOW SLAVE STATUS语句查看slave的设置是否正确：mysql> SHOW SLAVE STATUS\\G
*************************** 1. row *************************** Slave_IO_State: Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60
Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 4
Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: No Slave_SQL_Running: No ...omitted... Seconds_Behind_Master: NULL
Slave_IO_State, Slave_IO_Running, 和Slave_SQL_Running是No
表明slave还没有开始复制过程。⽇志的位置为4⽽不是0，这是因为0只是⽇志⽂件的开始位置，并不是⽇志位置。实际上，MySQL知道的第⼀个事件的位置是4。为了开始复制，你可以运⾏：mysql> START SLAVE;
运⾏SHOW SLAVE STATUS查看输出结果：mysql> SHOW SLAVE STATUS\\G
*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: server1 Master_User: repl Master_Port: 3306 Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 164
Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 164
Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes ...omitted... Seconds_Behind_Master: 0
在这⾥主要是看:
Slave_IO_Running=Yes Slave_SQL_Running=Yes
slave的I/O和SQL线程都已经开始运⾏，⽽且Seconds_Behind_Master不再是NULL。⽇志的位置增加了，意味着⼀些事件被获取并执⾏了。如果你在master上进⾏修改，你可以在slave上看到各种⽇志⽂件的位置的变化，同样，你也可以看到数据库中数据的变化。你可查看master和slave上线程的状态。在master上，你可以看到slave的I/O线程创建的连接：在master上输⼊show processlist\\G;mysql> show processlist \\G
*************************** 1. row *************************** Id: 1 User: root
Host: localhost:2096 db: testCommand: Query Time: 0 State: NULL
Info: show processlist
*************************** 2. row *************************** Id: 2 User: repl
Host: localhost:2144 db: NULL
Command: Binlog Dump Time: 1838
State: Has sent all binlog to slave; waiting for binlog to be updated Info: NULL
2 rows in set (0.00 sec)
⾏2为处理slave的I/O线程的连接。在slave服务器上运⾏该语句：mysql> show processlist \\G
*************************** 1. row *************************** Id: 1
User: system user Host: db: NULLCommand: Connect Time: 2291
State: Waiting for master to send event Info: NULL
*************************** 2. row *************************** Id: 2
User: system user Host: db: NULLCommand: Connect Time: 1852
State: Has read all relay log; waiting for the slave I/O thread to update it Info: NULL
*************************** 3. row *************************** Id: 5 User: root
Host: localhost:2152 db: testCommand: Query Time: 0 State: NULL
Info: show processlist3 rows in set (0.00 sec)
⾏1为I/O线程状态，⾏2为SQL线程状态。
2.5、添加新slave服务器
假如master已经运⾏很久了，想对新安装的slave进⾏数据同步，甚⾄它没有master的数据。
此时，有⼏种⽅法可以使slave从另⼀个服务开始，例如，从master拷贝数据，从另⼀个slave克隆，从最近的备份开始⼀个slave。Slave与master同步时，需要三样东西：(1)master的某个时刻的数据快照；
(2)master当前的⽇志⽂件、以及⽣成快照时的字节偏移。这两个值可以叫做⽇志⽂件坐标(log file coordinate)，因为它们确定了⼀个⼆进制⽇志的位置，你可以⽤SHOW MASTER STATUS命令找到⽇志⽂件的坐标；(3)master的⼆进制⽇志⽂件。
可以通过以下⼏中⽅法来克隆⼀个slave：(1) 冷拷贝(cold copy)
停⽌master，将master的⽂件拷贝到slave；然后重启master。缺点很明显。(2) 热拷贝(warm copy)
如果你仅使⽤MyISAM表，你可以使⽤mysqlhotcopy拷贝，即使服务器正在运⾏。(3) 使⽤mysqldump
使⽤mysqldump来得到⼀个数据快照可分为以下⼏步：
<1>锁表：如果你还没有锁表，你应该对表加锁，防⽌其它连接修改数据库，否则，你得到的数据可以是不⼀致的。如下：mysql> FLUSH TABLES WITH READ LOCK;
<2>在另⼀个连接⽤mysqldump创建⼀个你想进⾏复制的数据库的转储：
shell> mysqldump --all-databases --lock-all-tables >dbdump.db<3>对表释放锁。
mysql> UNLOCK TABLES;
3、深⼊了解复制
已经讨论了关于复制的⼀些基本东西，下⾯深⼊讨论⼀下复制。
3.1、基于语句的复制(Statement-Based Replication)
MySQL 5.0及之前的版本仅⽀持基于语句的复制（也叫做逻辑复制，logical replication），这在数据库并不常见。master记录下改变数据的查询，然后，slave从中继⽇志中读取事件，并执⾏它，这些SQL语句与 master执⾏的语句⼀样。
这种⽅式的优点就是实现简单。此外，基于语句的复制的⼆进制⽇志可以很好的进⾏压缩，⽽且⽇志的数据量也较⼩，占⽤带宽少——例如，⼀个更新GB的数据的查询仅需要⼏⼗个字节的⼆进制⽇志。⽽mysqlbinlog对于基于语句的⽇志处理⼗分⽅便。
但是，基于语句的复制并不是像它看起来那么简单，因为⼀些查询语句依赖于master的特定条件，例如，master与slave可能有不同的时间。所 以，MySQL的⼆进制⽇志的格式不仅仅是查询语句，还包括⼀些元数据信息，例如，当前的时间戳。即使如此，还是有⼀些语句，⽐如，CURRENT USER函数，不能正确的进⾏复制。此外，存储过程和触发器也是⼀个问题。
另外⼀个问题就是基于语句的复制必须是串⾏化的。这要求⼤量特殊的代码，配置，例如InnoDB的next-key锁等。并不是所有的存储引擎都⽀持基于语句的复制。
3.2、基于记录的复制(Row-Based Replication)
MySQL增加基于记录的复制，在⼆进制⽇志中记录下实际数据的改变，这与其它⼀些DBMS的实现⽅式类似。这种⽅式有优点，也有缺点。优点就是可以对任 何语句都能正确⼯作，⼀些语句的效率更⾼。主要的缺点就是⼆进制⽇志可能会很⼤，⽽且不直观，所以，你不能使⽤mysqlbinlog来查看⼆进制⽇志。
对于⼀些语句，基于记录的复制能够更有效的⼯作，如：mysql> INSERT INTO summary_table(col1, col2, sum_col3) -> SELECT col1, col2, sum(col3) -> FROM enormous_table -> GROUP BY col1, col2;
假设，只有三种唯⼀的col1和col2的组合，但是，该查询会扫描原表的许多⾏，却仅返回三条记录。此时，基于记录的复制效率更⾼。 另⼀⽅⾯，下⾯的语句，基于语句的复制更有效： mysql> UPDATE enormous_table SET col1 = 0;
此时使⽤基于记录的复制代价会⾮常⾼。由于两种⽅式不能对所有情况都能很好的处理，所以，MySQL 5.1⽀持在基于语句的复制和基于记录的复制之前动态交换。你可以通过设置session变量binlog_format来进⾏控制。
3.3、复制相关的⽂件
除了⼆进制⽇志和中继⽇志⽂件外，还有其它⼀些与复制相关的⽂件。如下：(1)mysql-bin.index
服务器⼀旦开启⼆进制⽇志，会产⽣⼀个与⼆⽇志⽂件同名，但是以.index结尾的⽂件。它⽤于跟踪磁盘上存在哪些⼆进制⽇志⽂件。MySQL⽤它来定位⼆进制⽇志⽂件。它的内容如下(我的机器上)：
(2)mysql-relay-bin.index
该⽂件的功能与mysql-bin.index类似，但是它是针对中继⽇志，⽽不是⼆进制⽇志。内容如下：.\\mysql-02-relay-bin.000017.\\mysql-02-relay-bin.000018(3)master.info
保存master的相关信息。不要删除它，否则，slave重启后不能连接master。内容如下(我的机器上)：
I/O线程更新master.info⽂件，内容如下(我的机器上)：
.\\mysql-02-relay-bin.000019254
mysql-01-bin.000010286052813
(4)relay-log.info
包含slave中当前⼆进制⽇志和中继⽇志的信息。
3.4、发送复制事件到其它slave
当设置log_slave_updates时，你可以让slave扮演其它slave的master。此时，slave把SQL线程执⾏的事件写进⾏⾃⼰的⼆进制⽇志(binarylog)，然后，它的slave可以获取这些事件并执⾏它。如下：
3.5、复制过滤(Replication Filters)
复制过滤可以让你只复制服务器中的⼀部分数据，有两种复制过滤：在master上过滤⼆进制⽇志中的事件；在slave上过滤中继⽇志中的事件。如下：
4、复制的常⽤拓扑结构
复制的体系结构有以下⼀些基本原则：(1) 每个slave只能有⼀个master；
(2) 每个slave只能有⼀个唯⼀的服务器ID；(3) 每个master可以有很多slave；
(4) 如果你设置log_slave_updates，slave可以是其它slave的master，从⽽扩散master的更新。
MySQL不⽀持多主服务器复制(Multimaster Replication)——即⼀个slave可以有多个master。但是，通过⼀些简单的组合，我们却可以建⽴灵活⽽强⼤的复制体系结构。
4.1、单⼀master和多slave
由⼀个master和⼀个slave组成复制系统是最简单的情况。Slave之间并不相互通信，只能与master进⾏通信。
在实际应⽤场景中，MySQL复制90%以上都是⼀个Master复制到⼀个或者多个Slave的架构模式，主要⽤于读压⼒⽐较⼤的应⽤的数据库端廉价扩展解决⽅案。因为只要Master和Slave的压⼒不是太⼤（尤其是Slave端压⼒）的话，异步复制的延时⼀般都很少很少。尤其是⾃从Slave端的复制⽅式改成两个线程处理之后，更是减⼩了Slave端的延时问题。⽽带来的效益是，对于数据实时性要求不是特别Critical的应⽤， 只需要通过廉价的pcserver来扩展Slave的数量，将读压⼒分散到多台Slave的机器上⾯，即可通过分散单台数据库服务器的读压⼒来解决数据库 端的读性能瓶颈，毕竟在⼤多数数据库应⽤系统中的读压⼒还是要⽐写压⼒⼤很多。这在很⼤程度上解决了⽬前很多中⼩型⽹站的数据库压⼒瓶颈问题，甚⾄有些⼤型⽹站也在使⽤类似⽅案解决数据库瓶颈。如下：
如果写操作较少，⽽读操作很时，可以采取这种结构。你可以将读操作分布到其它的slave，从⽽减⼩master的压⼒。但是，当slave增加到⼀定数量时，slave对master的负载以及⽹络带宽都会成为⼀个严重的问题。
这种结构虽然简单，但是，它却⾮常灵活，⾜够满⾜⼤多数应⽤需求。⼀些建议：(1) 不同的slave扮演不同的作⽤(例如使⽤不同的索引，或者不同的存储引擎)；(2) ⽤⼀个slave作为备⽤master，只进⾏复制；(3) ⽤⼀个远程的slave，⽤于灾难恢复；
⼤家应该都⽐较清楚，从⼀个Master节点可以复制出多个Slave节点，可能有⼈会想，那⼀个Slave节点是否可以从多个Master节点上⾯进⾏复制呢？⾄少在⽬前来看，MySQL是做不到的，以后是否会⽀持就不清楚了。
MySQL不⽀持⼀个Slave节点从多个Master节点来进⾏复制的架构，主要是为了避免冲突的问题，防⽌多个数据源之间的数据出现冲突，⽽造 成最后数据的不⼀致性。不过听说已经有⼈开发了相关的patch，让MySQL⽀持⼀个Slave节点从多个Master结点作为数据源来进⾏复制，这也 正是MySQL开源的性质所带来的好处。
4.2、主动模式的Master-Master(Master-Master in Active-Active Mode)
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中，就更不⽤担⼼可能会出现循环复制的情形了。如图：
主动的Master-Master复制有⼀些特殊的⽤处。例如，地理上分布的两个部分都需要⾃⼰的可写的数据副本。这种结构最⼤的问题就是更新冲突。假设⼀个表只有⼀⾏(⼀列)的数据，其值为1，如果两个服务器分别同时执⾏如下语句：在第⼀个服务器上执⾏：
mysql> UPDATE tbl SET col=col + 1;在第⼆个服务器上执⾏：
mysql> UPDATE tbl SET col=col * 2;
那么结果是多少呢？⼀台服务器是4，另⼀个服务器是3，但是，这并不会产⽣错误。
实际上，MySQL并不⽀持其它⼀些DBMS⽀持的多主服务器复制(Multimaster Replication)，这是MySQL的复制功能很⼤的⼀个限制(多主服务器的难点在于解决更新冲突)，但是，如果你实在有这种需求，你可以采⽤MySQL Cluster，以及将Cluster和Replication结合起来，可以建⽴强⼤的⾼性能的数据库平台。但是，可以通过其它⼀些⽅式来模拟这种多主服务器的复制。
4.3、主动-被动模式的Master-Master(Master-Master in Active-Passive Mode)
这是master-master结构变化⽽来的，它避免了M-M的缺点，实际上，这是⼀种具有容错和⾼可⽤性的系统。它的不同点在于其中⼀个服务只能进⾏只读操作。如图：
4.4 级联复制架构 Master –Slaves - Slaves
在有些应⽤场景中，可能读写压⼒差别⽐较⼤，读压⼒特别的⼤，⼀个Master可能需要上10台甚⾄更多的Slave才能够⽀撑注读的压⼒。这时 候，Master就会⽐较吃⼒了，因为仅仅连上来的SlaveIO线程就⽐较多了，这样写的压⼒稍微⼤⼀点的时候，Master端因为复制就会消耗较多的 资源，很容易造成复制的延时。
遇到这种情况如何解决呢？这时候我们就可以利⽤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总量也就会越多，我们没有⾮常明显的感觉，仅仅只是因为分散到了多台机器上⾯，所以不是很容易表现出来。此外，增加复制的级联层次，同⼀个变更传到最底层的Slave所需要经过的MySQL也会更多，同样可能造成延时较长的风险。⽽如果我们通过分拆集群的⽅式来解决的话，可能就会要好很多了，当然，分拆集群也需要更复杂的技术和更复杂的应⽤系统架构。
4.5、带从服务器的Master-Master结构(Master-Master with Slaves)
这种结构的优点就是提供了冗余。在地理上分布的复制结构，它不存在单⼀节点故障问题，⽽且还可以将读密集型的请求放到slave上。
级联复制在⼀定程度上⾯确实解决了Master因为所附属的Slave过多⽽成为瓶颈的问题，但是他并不能解决⼈⼯维护和出现异常需要切换后可能存 在重新搭建Replication的问题。这样就很⾃然的引申出了DualMaster与级联复制结合的Replication架构，我称之为 Master-Master-Slaves架构
和Master-Slaves-Slaves架构相⽐，区别仅仅只是将第⼀级Slave集群换成了⼀台单独的Master，作为备⽤Master，然后再从这个备⽤的Master进⾏复制到⼀个Slave集群。
这种DualMaster与级联复制结合的架构，最⼤的好处就是既可以 避免主Master的写⼊操作不会受到Slave集群的复制所带来的影响，同时主Master需要切换的时候也基本上不会出现重搭Replication 的情况。但是，这个架构也有⼀个弊端，那就是备⽤的Master有可能成为瓶颈，因为如果后⾯的Slave集群⽐较⼤的话，备⽤Master可能会因为过 多的SlaveIO线程请求⽽成为瓶颈。当然，该备⽤Master不提供任何的读服务的时候，瓶颈出现的可能性并不是特 别⾼，如果出现瓶颈，也可以在备⽤Master后⾯再次进⾏级联复制，架设多层Slave集群。当然，级联复制的级别越多，Slave集群可能出现的数据 延时也会更为明显，所以考虑使⽤多层级联复制之前，也需要评估数据延时对应⽤系统的影响。
因篇幅问题不能全部显示，请点此查看更多更全内容