總結:
主庫(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 [email protected]’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）上，并重新執行一遍來實作的。複制過程中一個伺服器充當主伺服器，而一個或多個其它伺服器充當從伺服器。主伺服器将更新寫入二進制日志檔案，并維護檔案的一個索引以跟蹤日志循環。這些日志可以記錄發送到從伺服器的更新。當一個從伺服器連接配接主伺服器時，它通知主伺服器從伺服器在日志中讀取的最後一次成功更新的位置。從伺服器接收從那時起發生的任何更新，然後封鎖并等待主伺服器通知新的更新。
請注意當你進行複制時，所有對複制中的表的更新必須在主伺服器上進行。否則，你必須要小心，以避免使用者對主伺服器上的表進行的更新與對從伺服器上的表所進行的更新之間的沖突。
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.10
IP位址：10.100.0.100
2.1、建立複制帳号
1、在Master的資料庫中建立一個備份帳戶：每個slave使用标準的MySQL使用者名和密碼連接配接master。進行複制操作的使用者會授予REPLICATION SLAVE權限。使用者名的密碼都會存儲在文本檔案master.info中
指令如下：
mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.*
TO [email protected]’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-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.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: 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線程的連接配接。
在slave伺服器上運作該語句：
| 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.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.000019 254 mysql-01-bin.000010 286 52813 |
(4)relay-log.info
包含slave中目前二進制日志和中繼日志的資訊。
3.4、發送複制事件到其它slave
當設定log_slave_updates時，你可以讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行自己的二進制日志(binary log)，然後，它的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叢集可能出現的資料延時也會更為明顯，是以考慮使用多層級聯複制之前，也需要評估資料延時對應用系統的影響。