mySql 主從複製linux配置

總結:

主庫(192.168.1.251):

/etc/my.cnf.d/server.cnf

[mysqld]
log-bin=mysql-bin
server-id=1

從庫(192.168.1.254):

/etc/my.cnf.d/server.cnf

[mysqld]
log-bin=mysql-bin
server-id=2

從新啓動主庫。從庫

在主庫中給從庫建立一個用於複製的帳號:

mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* 
TO backup@’192.168.1.254’ 
IDENTIFIED BY ‘1234’;

從庫操做:

     設置主庫 :

    

MariaDB [test]> change master to master_host='192.168.1.251',
    -> master_user='backup',
    -> master_password='1234',
    -> master_log_file='mysql-bin.000001',
    -> master_log_pos=0;
Query OK, 0 rows affected (0.02 sec)


MariaDB [test]> show slave status;

     啓動複製:

     
MariaDB [test]> START SLAVE;
Query OK, 0 rows affected (0.00 sec)

下面是別人的轉載至：

http://blog.csdn.net/hguisu/article/details/7325124

1 複製概述

      Mysql內建的複製功能是構建大型，高性能應用程序的基礎。將Mysql的數據分佈到多個系統上去，這樣的分佈的機制，是經過將Mysql的某一臺主機的數據拷貝到其餘主機（slaves）上，並又一次運行一遍來實現的。複製過程當中一個server充當主server。而一個或多個其餘server充當從server。

主server將更新寫入二進制日誌文件，並維護文件的一個索引以跟蹤日誌循環。這些日誌可以記錄發送到從server的更新。當一個從server鏈接主server時。它通知主server從server在日誌中讀取的最後一次成功更新的位置。從server接收從那時起發生的不論什麼更新，而後封鎖並等待主server通知新的更新。

請注意當你進行復制時。所有對複製中的表的更新必須在主server上進行。不然，你必須要當心，以免用戶對主server上的表進行的更新與對從server上的表所進行的更新之間的衝突。

1.1 mysql支持的複製類型：

　　（１）：基於語句的複製：  在主server上運行的SQL語句。在從server上運行相同的語句。

MySQL默認採用基於語句的複製，效率比較高。

  
            一旦發現無法精確複製時，   會本身主動選着基於行的複製。    
　　（２）：基於行的複製：把改變的內容複製過去，而不是把命令在從server上運行一遍. 從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數據庫serverMaster和slave，Master爲主server，slave爲從server。初始狀態時。Master和slave中的數據信息一樣，當Master中的數據發生變化時，slave也跟着發生對應的變化。使得master和slave的數據信息同步，達到備份的目的。

要點：
負責在主、從server傳輸各類修修改做的媒介是主server的二進制變動日誌。這個日誌記載着需要傳輸給從server的各類修修改做。

所以。主server必須激活二進制日誌功能。

從server必須具有足以讓它鏈接主server並請求主server把二進制變動日誌傳輸給它的權限。
        
環境：
Master和slave的MySQL數據庫版本號同爲5.0.18
操做系統：unbuntu 11.10
IP地址：10.100.0.100

2.一、建立複製賬號

一、在Master的數據庫中創建一個備份賬戶：每個slave使用標準的MySQLusername和password鏈接master。進行復制操做的用戶會授予REPLICATION SLAVE權限。username的password都會存儲在文本文件master.info中

命令例如如下：
mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* 
TO backup@’10.100.0.200’ 
IDENTIFIED BY ‘1234’;

創建一個賬戶backup，並且僅僅能贊成從10.100.0.200這個地址上來登錄，password是1234。

(假設因爲mysql版本號新舊密碼算法不一樣。可以設置：set password for 'backup'@'10.100.0.200'=old_password('1234')）

2.二、拷貝數據

（假如是你全然新安裝mysql主從server，這個一步就不需要。因爲新安裝的master和slave有一樣的數據）

關停Masterserver，將Master中的數據複製到Bserver中，使得Master和slave中的數據同步，並且確保在全部設置操做結束前，禁止在Master和slaveserver中進行寫操做。使得兩數據庫中的數據必定要一樣。

2.三、配置master

接下來對master進行配置。包含打開二進制日誌。指定惟一的servr ID。

好比。在配置文件增長例如如下值：

server-id=1
log-bin=mysql-bin

server-id：爲主服務器A的ID值
log-bin：二進制變動日值

從新啓動master，執行SHOW MASTER STATUS，輸出例如如下：

2.四、配置slave

Slave的配置與master相似，你相同需要從新啓動slave的MySQL。例如如下：
log_bin           = mysql-bin
server_id         = 2
relay_log         = mysql-relay-bin
log_slave_updates = 1
read_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.五、啓動slave

接下來就是讓slave鏈接master，並開始重作master二進制日誌中的事件。你不該該用配置文件進行該操做，而應該使用CHANGE MASTER TO語句，該語句可以全然代替對配置文件的改動。而且它可以爲slave指定不一樣的master。而不需要中止server。

例如如下：

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: test Command: 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線程的鏈接。

在slaveserver上執行該語句：

mysql> show processlist \G *************************** 1. row ***************************      Id: 1    User: system user    Host:      db: NULL Command: Connect    Time: 2291  State: Waiting for master to send event    Info: NULL *************************** 2. row ***************************      Id: 2    User: system user    Host:      db: NULL Command: 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: test Command: Query    Time: 0  State: NULL    Info: show processlist 3 rows in set (0.00 sec)

行1爲I/O線程狀態。行2爲SQL線程狀態。

2.五、加入新slaveserver

假如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拷貝。即便server正在執行。
(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.一、基於語句的複製(Statement-Based Replication)

     MySQL 5.0及以前的版本號僅支持基於語句的複製（也叫作邏輯複製，logical replication）。這在數據庫並不常見。

master記錄下改變數據的查詢，而後，slave從中繼日誌中讀取事件，並運行它，這些SQL語句與master運行的語句同樣。

這樣的方式的長處就是實現簡單。

此外，基於語句的複製的二進制日誌可以很是好的進行壓縮。而且日誌的數據量也較小，佔用帶寬少——好比，一個更新GB的數據的查詢僅需要幾十個字節的二進制日誌。而mysqlbinlog對於基於語句的日誌處理十分方便。

 
      但是。基於語句的複製並不是像它看起來那麼簡單，因爲一些查詢語句依賴於master的特定條件，好比。master與slave可能有不一樣的時間。因此，MySQL的二進制日誌的格式不不過查詢語句，還包含一些元數據信息。好比，當前的時間戳。

即便如此，仍是有一些語句，比方，CURRENT USER函數。不能正確的進行復制。

此外。存儲過程和觸發器也是一個問題。

     另一個問題就是基於語句的複製必須是串行化的。

這要求大量特殊的代碼。配置，好比InnoDB的next-key鎖等。並不是所有的存儲引擎都支持基於語句的複製。

3.二、基於記錄的複製(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.三、複製相關的文件

除了二進制日誌和中繼日誌文件外，還有其餘一些與複製相關的文件。例如如下：

(1)mysql-bin.index

server一旦開啓二進制日誌，會產生一個與二日誌文件同名，但是以.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.000019 254 mysql-01-bin.000010 286 0 52813

 (4)relay-log.info 

包括slave中當前二進制日誌和中繼日誌的信息。

3.四、發送複製事件到其餘slave

當設置log_slave_updates時，你可以讓slave扮演其餘slave的master。此時，slave把SQL線程運行的事件寫進行本身的二進制日誌(binary log)，而後。它的slave可以獲取這些事件並運行它。例如如下：

 

3.五、複製過濾(Replication Filters)

複製過濾可以讓你僅僅複製server中的一部分數據。有兩種複製過濾：在master上過濾二進制日誌中的事件；在slave上過濾中繼日誌中的事件。例如如下：

四、複製的常用拓撲結構

複製的體系結構有下面一些基本原則：
(1)    每個slave僅僅能有一個master。
(2)    每個slave僅僅能有一個惟一的serverID；
(3)    每個master可以有很是多slave；
(4)    假設你設置log_slave_updates，slave可以是其餘slave的master，從而擴散master的更新。

MySQL不支持多主server複製(Multimaster Replication)——即一個slave可以有多個master。

但是。經過一些簡單的組合，咱們卻可以創建靈活而強大的複製體系結構。

4.一、單一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.二、主動模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master複製的兩臺server。既是master，又是還有一臺server的slave。這樣，不論什麼一方所作的變動，都會經過複製應用到另一方的數據庫中。

可能有些讀者朋友會有一個操心，這樣搭建複製環境以後。難道不會形成兩臺MySQL之間的循環複製麼？實際上MySQL本身早就想到了這一點。因此在MySQL的BinaryLog中記錄了當前MySQL的server-id，而且這個參數也是咱們搭建MySQLReplication的時候必須明白指定。而且Master和Slave的server-id參數值比需要不一致才幹使MySQLReplication搭建成功。一旦有了server-id的值以後。MySQL就很是easy推斷某個變動是從哪個MySQLServer最初產生的，因此就很是easy避免出現循環複製的狀況。而且。假設咱們不打開記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄複製過程當中的變動到BinaryLog中，就更不用操心可能會出現循環複製的情形了。

 

如圖：

主動的Master-Master複製有一些特殊的用處。好比，地理上分佈的兩個部分都需要本身的可寫的數據副本。

這樣的結構最大的問題就是更新衝突。

若是一個表僅僅有一行(一列)的數據，其值爲1，若是兩個server分別同一時候運行例如如下語句：
在第一個server上運行：
mysql> UPDATE tbl SET col=col + 1;
在第二個server上運行：
mysql> UPDATE tbl SET col=col * 2;
那麼結果是多少呢？一臺server是4，還有一個server是3，但是，這並不會產生錯誤。
實際上。MySQL並不支持其餘一些DBMS支持的多主server複製(Multimaster Replication)，這是MySQL的複製功能很是大的一個限制(多主server的難點在於解決更新衝突)，但是。假設你實在有這樣的需求，你可以採用MySQL Cluster。以及將Cluster和Replication結合起來。可以創建強大的高性能的數據庫平臺。但是。可以經過其餘一些方式來模擬這樣的多主server的複製。

4.三、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)

這是master-master結構變化而來的。它避免了M-M的缺點，實際上，這是一種具備容錯和高可用性的系統。它的不一樣點在於當中一個服務僅僅能進行僅僅讀操做。如圖：

 

 

4.4 級聯複製架構 Master –Slaves - Slaves

在有些應用場景中，可能讀寫壓力區別比較大，讀壓力特別的大，一個Master可能需要上10臺甚至不少其它的Slave才能夠支撐注讀的壓力。這時候，Master就會比較吃力了。因爲只連上來的SlaveIO線程就比較多了。這樣寫的壓力略微大一點的時候，Master端因爲複製就會消耗較多的資源，很是easy形成複製的延時。

遇到這樣的狀況怎樣解決呢？這時候咱們就可以利用MySQL可以在Slave端記錄複製所產生變動的BinaryLog信息的功能，也就是打開—log-slave-update選項。

而後，經過二級（或者是不少其它級別）複製來下降Master端因爲複製所帶來的壓力。也就是說，咱們首先經過少數幾臺MySQL從Master來進行復制。這幾臺機器咱們姑且稱之爲第一級Slave集羣。而後其它的Slave再從第一級Slave集羣來進行復制。

從第一級Slave進行復制的Slave，我稱之爲第二級Slave集羣。假設有需要。咱們可以繼續往下添加不少其它層次的複製。這樣。咱們很是easy就控制了每一臺MySQL上面所附屬Slave的數量。這樣的架構我稱之爲Master-Slaves-Slaves架構

這樣的多層級聯複製的架構，很是easy就攻克了Master端因爲附屬Slave太多而成爲瓶頸的風險。

下圖展現了多層級聯複製的Replication架構。

固然，假設條件贊成，我更傾向於建議你們經過拆分紅多個Replication集羣來解決

上述瓶頸問題。

畢竟Slave並無下降寫的量，所有Slave實際上仍然仍是應用了所有的數據變動操做，沒有下降不論什麼寫IO。

相反，Slave越多。整個集羣的寫IO總量也就會越多，咱們沒有很是明顯的感受，只不過因爲分散到了多臺機器上面，因此不是很是easy表現出來。

此外，添加複製的級聯層次，同一個變動傳到最底層的Slave所需要通過的MySQL也會不少其它。相同可能形成延時較長的風險。

而假設咱們經過分拆集羣的方式來解決的話，可能就會要好很是多了，固然，分拆集羣也需要更復雜的技術和更復雜的應用系統架構。

 4.五、帶從server的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集羣可能出現的數據延時也會更爲明顯。因此考慮使用多層級聯複製以前，也需要評估數據延時相應用系統的影響。