1 復(fù)制概述
Mysql內(nèi)建的復(fù)制功能是構(gòu)建大型，高性能應(yīng)用程序的基礎(chǔ)。將Mysql的數(shù)據(jù)分布到多個系統(tǒng)上去，這種分布的機(jī)制，是通過將Mysql的某一臺主機(jī)的數(shù)據(jù)復(fù)制到其它主機(jī)（slaves）上，并重新執(zhí)行一遍來實現(xiàn)的。復(fù)制過程中一個服務(wù)器充當(dāng)主服務(wù)器，而一個或多個其它服務(wù)器充當(dāng)從服務(wù)器。主服務(wù)器將更新寫入二進(jìn)制日志文件，并維護(hù)文件的一個索引以跟蹤日志循環(huán)。這些日志可以記錄發(fā)送到從服務(wù)器的更新。當(dāng)一個從服務(wù)器連接主服務(wù)器時，它通知主服務(wù)器從服務(wù)器在日志中讀取的最后一次成功更新的位置。從服務(wù)器接收從那時起發(fā)生的任何更新，然后封鎖并等待主服務(wù)器通知新的更新。
請注意當(dāng)你進(jìn)行復(fù)制時，所有對復(fù)制中的表的更新必須在主服務(wù)器上進(jìn)行。否則，你必須要小心，以避免用戶對主服務(wù)器上的表進(jìn)行的更新與對從服務(wù)器上的表所進(jìn)行的更新之間的沖突。
1.1 mysql支持的復(fù)制類型：
（１）：基于語句的復(fù)制： 在主服務(wù)器上執(zhí)行的SQL語句，在從服務(wù)器上執(zhí)行同樣的語句。MySQL默認(rèn)采用基于語句的復(fù)制，效率比較高。
一旦發(fā)現(xiàn)沒法精確復(fù)制時， 會自動選著基于行的復(fù)制。
（２）：基于行的復(fù)制：把改變的內(nèi)容復(fù)制過去，而不是把命令在從服務(wù)器上執(zhí)行一遍. 從mysql5.0開始支持
（３）：混合類型的復(fù)制: 默認(rèn)采用基于語句的復(fù)制，一旦發(fā)現(xiàn)基于語句的無法精確的復(fù)制時，就會采用基于行的復(fù)制。
1.2 . 復(fù)制解決的問題
MySQL復(fù)制技術(shù)有以下一些特點：
(1) 數(shù)據(jù)分布 (Data distribution )
(2) 負(fù)載平衡(load balancing)
(3) 備份(Backups)
(4) 高可用性和容錯行 High availability and failover
1.3 復(fù)制如何工作
整體上來說，復(fù)制有3個步驟：
(1) master將改變記錄到二進(jìn)制日志(binary log)中（這些記錄叫做二進(jìn)制日志事件，binary log events）；
(2) slave將master的binary log events拷貝到它的中繼日志(relay log)；
(3) slave重做中繼日志中的事件，將改變反映它自己的數(shù)據(jù)。
下圖描述了復(fù)制的過程：
該過程的第一部分就是master記錄二進(jìn)制日志。在每個事務(wù)更新數(shù)據(jù)完成之前，master在二日志記錄這些改變。MySQL將事務(wù)串行的寫入二進(jìn)制日志，即使事務(wù)中的語句都是交叉執(zhí)行的。在事件寫入二進(jìn)制日志完成后，master通知存儲引擎提交事務(wù)。
下一步就是slave將master的binary log拷貝到它自己的中繼日志。首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，然后開始binlog dump process。Binlog dump process從master的二進(jìn)制日志中讀取事件，如果已經(jīng)跟上master，它會睡眠并等待master產(chǎn)生新的事件。I/O線程將這些事件寫入中繼日志。
SQL slave thread（SQL從線程）處理該過程的最后一步。SQL線程從中繼日志讀取事件，并重放其中的事件而更新slave的數(shù)據(jù)，使其與master中的數(shù)據(jù)一致。只要該線程與I/O線程保持一致，中繼日志通常會位于OS的緩存中，所以中繼日志的開銷很小。
此外，在master中也有一個工作線程：和其它MySQL的連接一樣，slave在master中打開一個連接也會使得master開始一個線程。復(fù)制過程有一個很重要的限制——復(fù)制在slave上是串行化的，也就是說master上的并行更新操作不能在slave上并行操作。
2 .復(fù)制配置
有兩臺MySQL數(shù)據(jù)庫服務(wù)器Master和slave，Master為主服務(wù)器，slave為從服務(wù)器，初始狀態(tài)時，Master和slave中的數(shù)據(jù)信息相同，當(dāng)Master中的數(shù)據(jù)發(fā)生變化時，slave也跟著發(fā)生相應(yīng)的變化，使得master和slave的數(shù)據(jù)信息同步，達(dá)到備份的目的。
要點：
負(fù)責(zé)在主、從服務(wù)器傳輸各種修改動作的媒介是主服務(wù)器的二進(jìn)制變更日志，這個日志記載著需要傳輸給從服務(wù)器的各種修改動作。因此，主服務(wù)器必須激活二進(jìn)制日志功能。從服務(wù)器必須具備足以讓它連接主服務(wù)器并請求主服務(wù)器把二進(jìn)制變更日志傳輸給它的權(quán)限。
環(huán)境：
Master和slave的MySQL數(shù)據(jù)庫版本同為5.0.18
操作系統(tǒng)：unbuntu 11.10
IP地址：10.100.0.100
2.1、創(chuàng)建復(fù)制賬號
1、在Master的數(shù)據(jù)庫中建立一個備份帳戶：每個slave使用標(biāo)準(zhǔn)的MySQL用戶名和密碼連接master。進(jìn)行復(fù)制操作的用戶會授予REPLICATION SLAVE權(quán)限。用戶名的密碼都會存儲在文本文件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版本新舊密碼算法不同，可以設(shè)置：set password for 'backup'@'10.100.0.200'=old_password('1234')）
2.2、拷貝數(shù)據(jù)
（假如是你完全新安裝mysql主從服務(wù)器，這個一步就不需要。因為新安裝的master和slave有相同的數(shù)據(jù)）
關(guān)停Master服務(wù)器，將Master中的數(shù)據(jù)拷貝到B服務(wù)器中，使得Master和slave中的數(shù)據(jù)同步，并且確保在全部設(shè)置操作結(jié)束前，禁止在Master和slave服務(wù)器中進(jìn)行寫操作，使得兩數(shù)據(jù)庫中的數(shù)據(jù)一定要相同！
2.3、配置master
接下來對master進(jìn)行配置，包括打開二進(jìn)制日志，指定唯一的servr ID。例如，在配置文件加入如下值：
server-id=1
log-bin=mysql-bin
server-id：為主服務(wù)器A的ID值
log-bin：二進(jìn)制變更日值
重啟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沒有必要開啟二進(jìn)制日志，但是在一些情況下，必須設(shè)置，例如，如果slave為其它slave的master，必須設(shè)置bin_log。在這里，我們開啟了二進(jìn)制日志，而且顯示的命名(默認(rèn)名稱為hostname，但是，如果hostname改變則會出現(xiàn)問題)。
relay_log配置中繼日志，log_slave_updates表示slave將復(fù)制事件寫進(jìn)自己的二進(jìn)制日志(后面會看到它的用處)。
有些人開啟了slave的二進(jìn)制日志，卻沒有設(shè)置log_slave_updates，然后查看slave的數(shù)據(jù)是否改變，這是一種錯誤的配置。所以，盡量使用read_only，它防止改變數(shù)據(jù)(除了特殊的線程)。但是，read_only并是很實用，特別是那些需要在slave上創(chuàng)建表的應(yīng)用。
2.5、啟動slave
接下來就是讓slave連接master，并開始重做master二進(jìn)制日志中的事件。你不應(yīng)該用配置文件進(jìn)行該操作，而應(yīng)該使用CHANGE MASTER TO語句，該語句可以完全取代對配置文件的修改，而且它可以為slave指定不同的master，而不需要停止服務(wù)器。如下：
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的設(shè)置是否正確：
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還沒有開始復(fù)制過程。日志的位置為4而不是0，這是因為0只是日志文件的開始位置，并不是日志位置。實際上，MySQL知道的第一個事件的位置是4。
為了開始復(fù)制，你可以運行：
mysql> START SLAVE;
運行SHOW SLAVE STATUS查看輸出結(jié)果：
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線程都已經(jīng)開始運行，而且Seconds_Behind_Master不再是NULL。日志的位置增加了，意味著一些事件被獲取并執(zhí)行了。如果你在master上進(jìn)行修改，你可以在slave上看到各種日志文件的位置的變化，同樣，你也可以看到數(shù)據(jù)庫中數(shù)據(jù)的變化。
你可查看master和slave上線程的狀態(tài)。在master上，你可以看到slave的I/O線程創(chuàng)建的連接：
在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服務(wù)器上運行該語句：
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線程狀態(tài)，行2為SQL線程狀態(tài)。
2.5、添加新slave服務(wù)器
假如master已經(jīng)運行很久了，想對新安裝的slave進(jìn)行數(shù)據(jù)同步，甚至它沒有master的數(shù)據(jù)。
此時，有幾種方法可以使slave從另一個服務(wù)開始，例如，從master拷貝數(shù)據(jù)，從另一個slave克隆，從最近的備份開始一個slave。Slave與master同步時，需要三樣?xùn)|西：
(1)master的某個時刻的數(shù)據(jù)快照；
(2)master當(dāng)前的日志文件、以及生成快照時的字節(jié)偏移。這兩個值可以叫做日志文件坐標(biāo)(log file coordinate)，因為它們確定了一個二進(jìn)制日志的位置，你可以用SHOW MASTER STATUS命令找到日志文件的坐標(biāo)；
(3)master的二進(jìn)制日志文件。
可以通過以下幾中方法來克隆一個slave：
(1) 冷拷貝(cold copy)
停止master，將master的文件拷貝到slave；然后重啟master。缺點很明顯。
(2) 熱拷貝(warm copy)
如果你僅使用MyISAM表，你可以使用mysqlhotcopy拷貝，即使服務(wù)器正在運行。
(3) 使用mysqldump
使用mysqldump來得到一個數(shù)據(jù)快照可分為以下幾步：
<1>鎖表：如果你還沒有鎖表，你應(yīng)該對表加鎖，防止其它連接修改數(shù)據(jù)庫，否則，你得到的數(shù)據(jù)可以是不一致的。如下：
mysql> FLUSH TABLES WITH READ LOCK;
<2>在另一個連接用mysqldump創(chuàng)建一個你想進(jìn)行復(fù)制的數(shù)據(jù)庫的轉(zhuǎn)儲：
shell> mysqldump --all-databases --lock-all-tables >dbdump.db
<3>對表釋放鎖。
mysql> UNLOCK TABLES;
3、深入了解復(fù)制
已經(jīng)討論了關(guān)于復(fù)制的一些基本東西，下面深入討論一下復(fù)制。
3.1、基于語句的復(fù)制(Statement-Based Replication)
MySQL 5.0及之前的版本僅支持基于語句的復(fù)制（也叫做邏輯復(fù)制，logical replication），這在數(shù)據(jù)庫并不常見。master記錄下改變數(shù)據(jù)的查詢，然后，slave從中繼日志中讀取事件，并執(zhí)行它，這些SQL語句與master執(zhí)行的語句一樣。
這種方式的優(yōu)點就是實現(xiàn)簡單。此外，基于語句的復(fù)制的二進(jìn)制日志可以很好的進(jìn)行壓縮，而且日志的數(shù)據(jù)量也較小，占用帶寬少——例如，一個更新GB的數(shù)據(jù)的查詢僅需要幾十個字節(jié)的二進(jìn)制日志。而mysqlbinlog對于基于語句的日志處理十分方便。
但是，基于語句的復(fù)制并不是像它看起來那么簡單，因為一些查詢語句依賴于master的特定條件，例如，master與slave可能有不同的時間。所以，MySQL的二進(jìn)制日志的格式不僅僅是查詢語句，還包括一些元數(shù)據(jù)信息，例如，當(dāng)前的時間戳。即使如此，還是有一些語句，比如，CURRENT USER函數(shù)，不能正確的進(jìn)行復(fù)制。此外，存儲過程和觸發(fā)器也是一個問題。
另外一個問題就是基于語句的復(fù)制必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。并不是所有的存儲引擎都支持基于語句的復(fù)制。
3.2、基于記錄的復(fù)制(Row-Based Replication)
MySQL增加基于記錄的復(fù)制，在二進(jìn)制日志中記錄下實際數(shù)據(jù)的改變，這與其它一些DBMS的實現(xiàn)方式類似。這種方式有優(yōu)點，也有缺點。優(yōu)點就是可以對任何語句都能正確工作，一些語句的效率更高。主要的缺點就是二進(jìn)制日志可能會很大，而且不直觀，所以，你不能使用mysqlbinlog來查看二進(jìn)制日志。
對于一些語句，基于記錄的復(fù)制能夠更有效的工作，如：
mysql> INSERT INTO summary_table(col1, col2, sum_col3)
-> SELECT col1, col2, sum(col3)
-> FROM enormous_table
-> GROUP BY col1, col2;
假設(shè)，只有三種唯一的col1和col2的組合，但是，該查詢會掃描原表的許多行，卻僅返回三條記錄。此時，基于記錄的復(fù)制效率更高。
另一方面，下面的語句，基于語句的復(fù)制更有效：
mysql> UPDATE enormous_table SET col1 = 0;
此時使用基于記錄的復(fù)制代價會非常高。由于兩種方式不能對所有情況都能很好的處理，所以，MySQL 5.1支持在基于語句的復(fù)制和基于記錄的復(fù)制之前動態(tài)交換。你可以通過設(shè)置session變量binlog_format來進(jìn)行控制。
3.3、復(fù)制相關(guān)的文件
除了二進(jìn)制日志和中繼日志文件外，還有其它一些與復(fù)制相關(guān)的文件。如下：
(1)mysql-bin.index
服務(wù)器一旦開啟二進(jìn)制日志，會產(chǎn)生一個與二日志文件同名，但是以.index結(jié)尾的文件。它用于跟蹤磁盤上存在哪些二進(jìn)制日志文件。MySQL用它來定位二進(jìn)制日志文件。它的內(nèi)容如下(我的機(jī)器上)：
(2)mysql-relay-bin.index
該文件的功能與mysql-bin.index類似，但是它是針對中繼日志，而不是二進(jìn)制日志。內(nèi)容如下：
.\mysql-02-relay-bin.000017
.\mysql-02-relay-bin.000018
(3)master.info
保存master的相關(guān)信息。不要刪除它，否則，slave重啟后不能連接master。內(nèi)容如下(我的機(jī)器上)：
I/O線程更新master.info文件，內(nèi)容如下(我的機(jī)器上)：
.\mysql-02-relay-bin.000019
254
mysql-01-bin.000010
286
0
52813
(4)relay-log.info
包含slave中當(dāng)前二進(jìn)制日志和中繼日志的信息。
3.4、發(fā)送復(fù)制事件到其它slave
當(dāng)設(shè)置log_slave_updates時，你可以讓slave扮演其它slave的master。此時，slave把SQL線程執(zhí)行的事件寫進(jìn)行自己的二進(jìn)制日志(binary log)，然后，它的slave可以獲取這些事件并執(zhí)行它。如下：
3.5、復(fù)制過濾(Replication Filters)
復(fù)制過濾可以讓你只復(fù)制服務(wù)器中的一部分?jǐn)?shù)據(jù)，有兩種復(fù)制過濾：在master上過濾二進(jìn)制日志中的事件；在slave上過濾中繼日志中的事件。如下：
4、復(fù)制的常用拓?fù)浣Y(jié)構(gòu)
復(fù)制的體系結(jié)構(gòu)有以下一些基本原則：
(1) 每個slave只能有一個master；
(2) 每個slave只能有一個唯一的服務(wù)器ID；
(3) 每個master可以有很多slave；
(4) 如果你設(shè)置log_slave_updates，slave可以是其它slave的master，從而擴(kuò)散master的更新。
MySQL不支持多主服務(wù)器復(fù)制(Multimaster Replication)——即一個slave可以有多個master。但是，通過一些簡單的組合，我們卻可以建立靈活而強(qiáng)大的復(fù)制體系結(jié)構(gòu)。
4.1、單一master和多slave
由一個master和一個slave組成復(fù)制系統(tǒng)是最簡單的情況。Slave之間并不相互通信，只能與master進(jìn)行通信。
在實際應(yīng)用場景中，MySQL復(fù)制90%以上都是一個Master復(fù)制到一個或者多個Slave的架構(gòu)模式，主要用于讀壓力比較大的應(yīng)用的數(shù)據(jù)庫端廉價擴(kuò)展解決方案。因為只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復(fù)制的延時一般都很少很少。尤其是自從Slave端的復(fù)制方式改成兩個線程處理之后，更是減小了Slave端的延時問題。而帶來的效益是，對于數(shù)據(jù)實時性要求不是特別Critical的應(yīng)用，只需要通過廉價的pcserver來擴(kuò)展Slave的數(shù)量，將讀壓力分散到多臺Slave的機(jī)器上面，即可通過分散單臺數(shù)據(jù)庫服務(wù)器的讀壓力來解決數(shù)據(jù)庫端的讀性能瓶頸，畢竟在大多數(shù)數(shù)據(jù)庫應(yīng)用系統(tǒng)中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網(wǎng)站的數(shù)據(jù)庫壓力瓶頸問題，甚至有些大型網(wǎng)站也在使用類似方案解決數(shù)據(jù)庫瓶頸。
如下：
如果寫操作較少，而讀操作很時，可以采取這種結(jié)構(gòu)。你可以將讀操作分布到其它的slave，從而減小master的壓力。但是，當(dāng)slave增加到一定數(shù)量時，slave對master的負(fù)載以及網(wǎng)絡(luò)帶寬都會成為一個嚴(yán)重的問題。
這種結(jié)構(gòu)雖然簡單，但是，它卻非常靈活，足夠滿足大多數(shù)應(yīng)用需求。一些建議：
(1) 不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲引擎)；
(2) 用一個slave作為備用master，只進(jìn)行復(fù)制；
(3) 用一個遠(yuǎn)程的slave，用于災(zāi)難恢復(fù)；
大家應(yīng)該都比較清楚，從一個Master節(jié)點可以復(fù)制出多個Slave節(jié)點，可能有人會想，那一個Slave節(jié)點是否可以從多個Master節(jié)點上面進(jìn)行復(fù)制呢？至少在目前來看，MySQL是做不到的，以后是否會支持就不清楚了。
MySQL不支持一個Slave節(jié)點從多個Master節(jié)點來進(jìn)行復(fù)制的架構(gòu)，主要是為了避免沖突的問題，防止多個數(shù)據(jù)源之間的數(shù)據(jù)出現(xiàn)沖突，而造成最后數(shù)據(jù)的不一致性。不過聽說已經(jīng)有人開發(fā)了相關(guān)的patch，讓MySQL支持一個Slave節(jié)點從多個Master結(jié)點作為數(shù)據(jù)源來進(jìn)行復(fù)制，這也正是MySQL開源的性質(zhì)所帶來的好處。
4.2、主動模式的Master-Master(Master-Master in Active-Active Mode)
Master-Master復(fù)制的兩臺服務(wù)器，既是master，又是另一臺服務(wù)器的slave。這樣，任何一方所做的變更，都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中。
可能有些讀者朋友會有一個擔(dān)心，這樣搭建復(fù)制環(huán)境之后，難道不會造成兩臺MySQL之間的循環(huán)復(fù)制么？實際上MySQL自己早就想到了這一點，所以在MySQL的BinaryLog中記錄了當(dāng)前MySQL的server-id，而且這個參數(shù)也是我們搭建MySQLReplication的時候必須明確指定，而且Master和Slave的server-id參數(shù)值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后，MySQL就很容易判斷某個變更是從哪一個MySQLServer最初產(chǎn)生的，所以就很容易避免出現(xiàn)循環(huán)復(fù)制的情況。而且，如果我們不打開記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄復(fù)制過程中的變更到BinaryLog中，就更不用擔(dān)心可能會出現(xiàn)循環(huán)復(fù)制的情形了。
如圖：
主動的Master-Master復(fù)制有一些特殊的用處。例如，地理上分布的兩個部分都需要自己的可寫的數(shù)據(jù)副本。這種結(jié)構(gòu)最大的問題就是更新沖突。假設(shè)一個表只有一行(一列)的數(shù)據(jù)，其值為1，如果兩個服務(wù)器分別同時執(zhí)行如下語句：
在第一個服務(wù)器上執(zhí)行：
mysql> UPDATE tbl SET col=col + 1;
在第二個服務(wù)器上執(zhí)行：
mysql> UPDATE tbl SET col=col * 2;
那么結(jié)果是多少呢？一臺服務(wù)器是4，另一個服務(wù)器是3，但是，這并不會產(chǎn)生錯誤。
實際上，MySQL并不支持其它一些DBMS支持的多主服務(wù)器復(fù)制(Multimaster Replication)，這是MySQL的復(fù)制功能很大的一個限制(多主服務(wù)器的難點在于解決更新沖突)，但是，如果你實在有這種需求，你可以采用MySQL Cluster，以及將Cluster和Replication結(jié)合起來，可以建立強(qiáng)大的高性能的數(shù)據(jù)庫平臺。但是，可以通過其它一些方式來模擬這種多主服務(wù)器的復(fù)制。
4.3、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)
這是master-master結(jié)構(gòu)變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統(tǒng)。它的不同點在于其中一個服務(wù)只能進(jìn)行只讀操作。如圖：
4.4 級聯(lián)復(fù)制架構(gòu) Master –Slaves - Slaves
在有些應(yīng)用場景中，可能讀寫壓力差別比較大，讀壓力特別的大，一個Master可能需要上10臺甚至更多的Slave才能夠支撐注讀的壓力。這時候，Master就會比較吃力了，因為僅僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點的時候，Master端因為復(fù)制就會消耗較多的資源，很容易造成復(fù)制的延時。
遇到這種情況如何解決呢？這時候我們就可以利用MySQL可以在Slave端記錄復(fù)制所產(chǎn)生變更的BinaryLog信息的功能，也就是打開—log-slave-update選項。然后，通過二級（或者是更多級別）復(fù)制來減少Master端因為復(fù)制所帶來的壓力。也就是說，我們首先通過少數(shù)幾臺MySQL從Master來進(jìn)行復(fù)制，這幾臺機(jī)器我們姑且稱之為第一級Slave集群，然后其他的Slave再從第一級Slave集群來進(jìn)行復(fù)制。從第一級Slave進(jìn)行復(fù)制的Slave，我稱之為第二級Slave集群。如果有需要，我們可以繼續(xù)往下增加更多層次的復(fù)制。這樣，我們很容易就控制了每一臺MySQL上面所附屬Slave的數(shù)量。這種架構(gòu)我稱之為Master-Slaves-Slaves架構(gòu)
這種多層級聯(lián)復(fù)制的架構(gòu)，很容易就解決了Master端因為附屬Slave太多而成為瓶頸的風(fēng)險。下圖展示了多層級聯(lián)復(fù)制的Replication架構(gòu)。
當(dāng)然，如果條件允許，我更傾向于建議大家通過拆分成多個Replication集群來解決
上述瓶頸問題。畢竟Slave并沒有減少寫的量，所有Slave實際上仍然還是應(yīng)用了所有的數(shù)據(jù)變更操作，沒有減少任何寫IO。相反，Slave越多，整個集群的寫IO總量也就會越多，我們沒有非常明顯的感覺，僅僅只是因為分散到了多臺機(jī)器上面，所以不是很容易表現(xiàn)出來。
此外，增加復(fù)制的級聯(lián)層次，同一個變更傳到最底層的Slave所需要經(jīng)過的MySQL也會更多，同樣可能造成延時較長的風(fēng)險。
而如果我們通過分拆集群的方式來解決的話，可能就會要好很多了，當(dāng)然，分拆集群也需要更復(fù)雜的技術(shù)和更復(fù)雜的應(yīng)用系統(tǒng)架構(gòu)。
4.5、帶從服務(wù)器的Master-Master結(jié)構(gòu)(Master-Master with Slaves)
這種結(jié)構(gòu)的優(yōu)點就是提供了冗余。在地理上分布的復(fù)制結(jié)構(gòu)，它不存在單一節(jié)點故障問題，而且還可以將讀密集型的請求放到slave上。
級聯(lián)復(fù)制在一定程度上面確實解決了Master因為所附屬的Slave過多而成為瓶頸的問題，但是他并不能解決人工維護(hù)和出現(xiàn)異常需要切換后可能存在重新搭建Replication的問題。這樣就很自然的引申出了DualMaster與級聯(lián)復(fù)制結(jié)合的Replication架構(gòu)，我稱之為Master-Master-Slaves架構(gòu)
和Master-Slaves-Slaves架構(gòu)相比，區(qū)別僅僅只是將第一級Slave集群換成了一臺單獨的Master，作為備用Master，然后再從這個備用的Master進(jìn)行復(fù)制到一個Slave集群。
這種DualMaster與級聯(lián)復(fù)制結(jié)合的架構(gòu)，最大的好處就是既可以避免主Master的寫入操作不會受到Slave集群的復(fù)制所帶來的影響，同時主Master需要切換的時候也基本上不會出現(xiàn)重搭Replication的情況。但是，這個架構(gòu)也有一個弊端，那就是備用的Master有可能成為瓶頸，因為如果后面的Slave集群比較大的話，備用Master可能會因為過多的SlaveIO線程請求而成為瓶頸。當(dāng)然，該備用Master不提供任何的讀服務(wù)的時候，瓶頸出現(xiàn)的可能性并不是特別高，如果出現(xiàn)瓶頸，也可以在備用Master后面再次進(jìn)行級聯(lián)復(fù)制，架設(shè)多層Slave集群。當(dāng)然，級聯(lián)復(fù)制的級別越多，Slave集群可能出現(xiàn)的數(shù)據(jù)延時也會更為明顯，所以考慮使用多層級聯(lián)復(fù)制之前，也需要評估數(shù)據(jù)延時對應(yīng)用系統(tǒng)的影響。
轉(zhuǎn)載自：
http://blog.csdn.net/hguisu/article/details/7325124
