高性能Mysql主從架構(gòu)的復(fù)制原理及配置示例

這篇文章主要介紹了高性能MySQL主從架構(gòu)的復(fù)制原理及配置示例，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供軹城網(wǎng)站建設(shè)、軹城做網(wǎng)站、軹城網(wǎng)站設(shè)計(jì)、軹城網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、軹城企業(yè)網(wǎng)站模板建站服務(wù)，10多年軹城做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

1 復(fù)制概述

---

Mysql內(nèi)建的復(fù)制功能是構(gòu)建大型，高性能應(yīng)用程序的基礎(chǔ)。將Mysql的數(shù)據(jù)分布到多個(gè)系統(tǒng)上去，這種分布的機(jī)制，是通過(guò)將Mysql的某一臺(tái)主機(jī)的數(shù)據(jù)復(fù)制到其它主機(jī)（slaves）上，并重新執(zhí)行一遍來(lái)實(shí)現(xiàn)的。復(fù)制過(guò)程中一個(gè)服務(wù)器充當(dāng)主服務(wù)器，而一個(gè)或多個(gè)其它服務(wù)器充當(dāng)從服務(wù)器。主服務(wù)器將更新寫(xiě)入二進(jìn)制日志文件，并維護(hù)文件的一個(gè)索引以跟蹤日志循環(huán)。這些日志可以記錄發(fā)送到從服務(wù)器的更新。當(dāng)一個(gè)從服務(wù)器連接主服務(wù)器時(shí)，它通知主服務(wù)器從服務(wù)器在日志中讀取的最后一次成功更新的位置。從服務(wù)器接收從那時(shí)起發(fā)生的任何更新，然后封鎖并等待主服務(wù)器通知新的更新。

請(qǐng)注意當(dāng)你進(jìn)行復(fù)制時(shí)，所有對(duì)復(fù)制中的表的更新必須在主服務(wù)器上進(jìn)行。否則，你必須要小心，以避免用戶對(duì)主服務(wù)器上的表進(jìn)行的更新與對(duì)從服務(wù)器上的表所進(jìn)行的更新之間的沖突。

1.1 mysql支持的復(fù)制類型：

（１）：基于語(yǔ)句的復(fù)制：  在主服務(wù)器上執(zhí)行的SQL語(yǔ)句，在從服務(wù)器上執(zhí)行同樣的語(yǔ)句。MySQL默認(rèn)采用基于語(yǔ)句的復(fù)制，效率比較高。  
            一旦發(fā)現(xiàn)沒(méi)法精確復(fù)制時(shí)，   會(huì)自動(dòng)選著基于行的復(fù)制。    
　?。ǎ玻夯谛械膹?fù)制：把改變的內(nèi)容復(fù)制過(guò)去，而不是把命令在從服務(wù)器上執(zhí)行一遍. 從mysql5.0開(kāi)始支持
　?。ǎ常夯旌项愋偷膹?fù)制: 默認(rèn)采用基于語(yǔ)句的復(fù)制，一旦發(fā)現(xiàn)基于語(yǔ)句的無(wú)法精確的復(fù)制時(shí)，就會(huì)采用基于行的復(fù)制。

1.2 . 復(fù)制解決的問(wèn)題

MySQL復(fù)制技術(shù)有以下一些特點(diǎn)：
         (1)    數(shù)據(jù)分布 (Data distribution )
         (2)    負(fù)載平衡(load balancing)
         (3)    備份(Backups)
         (4)    高可用性和容錯(cuò)行 High availability and failover

 1.3 復(fù)制如何工作

整體上來(lái)說(shuō)，復(fù)制有3個(gè)步驟：

(1)    master將改變記錄到二進(jìn)制日志(binary log)中（這些記錄叫做二進(jìn)制日志事件，binary log events）；
       (2)    slave將master的binary log events拷貝到它的中繼日志(relay log)；

(3)    slave重做中繼日志中的事件，將改變反映它自己的數(shù)據(jù)。

下圖描述了復(fù)制的過(guò)程：

該過(guò)程的第一部分就是master記錄二進(jìn)制日志。在每個(gè)事務(wù)更新數(shù)據(jù)完成之前，master在二日志記錄這些改變。MySQL將事務(wù)串行的寫(xiě)入二進(jìn)制日志，即使事務(wù)中的語(yǔ)句都是交叉執(zhí)行的。在事件寫(xiě)入二進(jìn)制日志完成后，master通知存儲(chǔ)引擎提交事務(wù)。
       下一步就是slave將master的binary log拷貝到它自己的中繼日志。首先，slave開(kāi)始一個(gè)工作線程——I/O線程。I/O線程在master上打開(kāi)一個(gè)普通的連接，然后開(kāi)始binlog dump process。Binlog dump process從master的二進(jìn)制日志中讀取事件，如果已經(jīng)跟上master，它會(huì)睡眠并等待master產(chǎn)生新的事件。I/O線程將這些事件寫(xiě)入中繼日志。
       SQL slave thread（SQL從線程）處理該過(guò)程的最后一步。SQL線程從中繼日志讀取事件，并重放其中的事件而更新slave的數(shù)據(jù)，使其與master中的數(shù)據(jù)一致。只要該線程與I/O線程保持一致，中繼日志通常會(huì)位于OS的緩存中，所以中繼日志的開(kāi)銷很小。
        此外，在master中也有一個(gè)工作線程：和其它MySQL的連接一樣，slave在master中打開(kāi)一個(gè)連接也會(huì)使得master開(kāi)始一個(gè)線程。復(fù)制過(guò)程有一個(gè)很重要的限制——復(fù)制在slave上是串行化的，也就是說(shuō)master上的并行更新操作不能在slave上并行操作。

2 .主從復(fù)制配置

---

有兩臺(tái)MySQL數(shù)據(jù)庫(kù)服務(wù)器Master和slave，Master為主服務(wù)器，slave為從服務(wù)器，初始狀態(tài)時(shí)，Master和slave中的數(shù)據(jù)信息相同，當(dāng)Master中的數(shù)據(jù)發(fā)生變化時(shí)，slave也跟著發(fā)生相應(yīng)的變化，使得master和slave的數(shù)據(jù)信息同步，達(dá)到備份的目的。

要點(diǎn)：
負(fù)責(zé)在主、從服務(wù)器傳輸各種修改動(dòng)作的媒介是主服務(wù)器的二進(jìn)制變更日志，這個(gè)日志記載著需要傳輸給從服務(wù)器的各種修改動(dòng)作。因此，主服務(wù)器必須激活二進(jìn)制日志功能。從服務(wù)器必須具備足以讓它連接主服務(wù)器并請(qǐng)求主服務(wù)器把二進(jìn)制變更日志傳輸給它的權(quán)限。
       
環(huán)境：
Master和slave的MySQL數(shù)據(jù)庫(kù)版本同為5.0.18
IP地址：10.100.0.100

2.1、創(chuàng)建復(fù)制帳號(hào)

1、在Master的數(shù)據(jù)庫(kù)中建立一個(gè)備份帳戶：每個(gè)slave使用標(biāo)準(zhǔn)的MySQL用戶名和密碼連接master。進(jìn)行復(fù)制操作的用戶會(huì)授予REPLICATION SLAVE權(quán)限。用戶名的密碼都會(huì)存儲(chǔ)在文本文件master.info中

命令如下：

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

建立一個(gè)帳戶backup，并且只能允許從10.100.0.200這個(gè)地址上來(lái)登陸，密碼是1234。

(如果因?yàn)閙ysql版本新舊密碼算法不同，可以設(shè)置：set password for 'backup'@'10.100.0.200'=old_password('1234')）

2.2、拷貝數(shù)據(jù)

（假如是你完全新安裝mysql主從服務(wù)器，這個(gè)一步就不需要。因?yàn)樾掳惭b的master和slave有相同的數(shù)據(jù)）

關(guān)停Master服務(wù)器，將Master中的數(shù)據(jù)拷貝到B服務(wù)器中，使得Master和slave中的數(shù)據(jù)同步，并且確保在全部設(shè)置操作結(jié)束前，禁止在Master和slave服務(wù)器中進(jìn)行寫(xiě)操作，使得兩數(shù)據(jù)庫(kù)中的數(shù)據(jù)一定要相同！

2.3、配置master

接下來(lái)對(duì)master進(jìn)行配置，包括打開(kāi)二進(jìn)制日志，指定唯一的servr ID。例如，在配置文件加入如下值：

server-id=1log-bin=mysql-binserver-id：為主服務(wù)器A的ID值log-bin：二進(jìn)制變更日值

重啟master，運(yùn)行SHOW MASTER STATUS，輸出如下：

2.4、配置slave

Slave的配置與master類似，你同樣需要重啟slave的MySQL。如下：

log_bin           = mysql-binserver_id         = 2relay_log         = mysql-relay-binlog_slave_updates = 1read_only         = 1

server_id：是必須的，而且唯一。

log_bin：slave沒(méi)有必要開(kāi)啟二進(jìn)制日志bin_log，但是在一些情況下，必須設(shè)置，例如，如果slave為其它slave的master，必須設(shè)置bin_log。在這里，我們開(kāi)啟了二進(jìn)制日志，而且顯示的命名(默認(rèn)名稱為hostname，但是，如果hostname改變則會(huì)出現(xiàn)問(wèn)題)。
relay_log：配置中繼日志，log_slave_updates表示slave將復(fù)制事件寫(xiě)進(jìn)自己的二進(jìn)制日志(后面會(huì)看到它的用處)。
有些人開(kāi)啟了slave的二進(jìn)制日志，卻沒(méi)有設(shè)置log_slave_updates，然后查看slave的數(shù)據(jù)是否改變，這是一種錯(cuò)誤的配置。

read_only：盡量使用read_only，它防止改變數(shù)據(jù)(除了特殊的線程)。但是，read_only并是很實(shí)用，特別是那些需要在slave上創(chuàng)建表的應(yīng)用。

2.5、啟動(dòng)slave

接下來(lái)就是讓slave連接master，并開(kāi)始重做master二進(jìn)制日志中的事件。你不應(yīng)該用配置文件進(jìn)行該操作，而應(yīng)該使用CHANGE MASTER TO語(yǔ)句，該語(yǔ)句可以完全取代對(duì)配置文件的修改，而且它可以為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，因?yàn)樗侨罩镜拈_(kāi)始位置。

你可以用SHOW SLAVE STATUS語(yǔ)句查看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: NULLSlave_IO_State, Slave_IO_Running, 和Slave_SQL_Running是No

表明slave還沒(méi)有開(kāi)始復(fù)制過(guò)程。日志的位置為4而不是0，這是因?yàn)?只是日志文件的開(kāi)始位置，并不是日志位置。實(shí)際上，MySQL知道的第一個(gè)事件的位置是4。

為了開(kāi)始復(fù)制，你可以運(yùn)行：

mysql> START SLAVE;運(yùn)行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)開(kāi)始運(yùn)行，而且Seconds_Behind_Master不再是NULL。日志的位置增加了，意味著一些事件被獲取并執(zhí)行了。如果你在master上進(jìn)行修改，你可以在slave上看到各種日志文件的位置的變化，同樣，你也可以看到數(shù)據(jù)庫(kù)中數(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ù)器上運(yùn)行該語(yǔ)句：

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)運(yùn)行很久了，想對(duì)新安裝的slave進(jìn)行數(shù)據(jù)同步，甚至它沒(méi)有master的數(shù)據(jù)。
此時(shí)，有幾種方法可以使slave從另一個(gè)服務(wù)開(kāi)始，例如，從master拷貝數(shù)據(jù)，從另一個(gè)slave克隆，從最近的備份開(kāi)始一個(gè)slave。Slave與master同步時(shí)，需要三樣?xùn)|西：
(1)master的某個(gè)時(shí)刻的數(shù)據(jù)快照；
(2)master當(dāng)前的日志文件、以及生成快照時(shí)的字節(jié)偏移。這兩個(gè)值可以叫做日志文件坐標(biāo)(log file coordinate)，因?yàn)樗鼈兇_定了一個(gè)二進(jìn)制日志的位置，你可以用SHOW MASTER STATUS命令找到日志文件的坐標(biāo)；
(3)master的二進(jìn)制日志文件。

可以通過(guò)以下幾中方法來(lái)克隆一個(gè)slave：
(1)    冷拷貝(cold copy)
停止master，將master的文件拷貝到slave；然后重啟master。缺點(diǎn)很明顯。
(2)    熱拷貝(warm copy)
如果你僅使用MyISAM表，你可以使用mysqlhotcopy拷貝，即使服務(wù)器正在運(yùn)行。
(3)    使用mysqldump
使用mysqldump來(lái)得到一個(gè)數(shù)據(jù)快照可分為以下幾步：
<1>鎖表：如果你還沒(méi)有鎖表，你應(yīng)該對(duì)表加鎖，防止其它連接修改數(shù)據(jù)庫(kù)，否則，你得到的數(shù)據(jù)可以是不一致的。如下：
mysql> FLUSH TABLES WITH READ LOCK;
<2>在另一個(gè)連接用mysqldump創(chuàng)建一個(gè)你想進(jìn)行復(fù)制的數(shù)據(jù)庫(kù)的轉(zhuǎn)儲(chǔ)：
shell> mysqldump --all-databases --lock-all-tables >dbdump.db
<3>對(duì)表釋放鎖。
mysql> UNLOCK TABLES;

3、深入了解復(fù)制

---

已經(jīng)討論了關(guān)于復(fù)制的一些基本東西，下面深入討論一下復(fù)制。

3.1、基于語(yǔ)句的復(fù)制(Statement-Based Replication)

MySQL 5.0及之前的版本僅支持基于語(yǔ)句的復(fù)制（也叫做邏輯復(fù)制，logical replication），這在數(shù)據(jù)庫(kù)并不常見(jiàn)。master記錄下改變數(shù)據(jù)的查詢，然后，slave從中繼日志中讀取事件，并執(zhí)行它，這些SQL語(yǔ)句與master執(zhí)行的語(yǔ)句一樣。
這種方式的優(yōu)點(diǎn)就是實(shí)現(xiàn)簡(jiǎn)單。此外，基于語(yǔ)句的復(fù)制的二進(jìn)制日志可以很好的進(jìn)行壓縮，而且日志的數(shù)據(jù)量也較小，占用帶寬少——例如，一個(gè)更新GB的數(shù)據(jù)的查詢僅需要幾十個(gè)字節(jié)的二進(jìn)制日志。而mysqlbinlog對(duì)于基于語(yǔ)句的日志處理十分方便。
 
      但是，基于語(yǔ)句的復(fù)制并不是像它看起來(lái)那么簡(jiǎn)單，因?yàn)橐恍┎樵冋Z(yǔ)句依賴于master的特定條件，例如，master與slave可能有不同的時(shí)間。所以，MySQL的二進(jìn)制日志的格式不僅僅是查詢語(yǔ)句，還包括一些元數(shù)據(jù)信息，例如，當(dāng)前的時(shí)間戳。即使如此，還是有一些語(yǔ)句，比如，CURRENT USER函數(shù)，不能正確的進(jìn)行復(fù)制。此外，存儲(chǔ)過(guò)程和觸發(fā)器也是一個(gè)問(wèn)題。
     另外一個(gè)問(wèn)題就是基于語(yǔ)句的復(fù)制必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。并不是所有的存儲(chǔ)引擎都支持基于語(yǔ)句的復(fù)制。

3.2、基于記錄的復(fù)制(Row-Based Replication)

MySQL增加基于記錄的復(fù)制，在二進(jìn)制日志中記錄下實(shí)際數(shù)據(jù)的改變，這與其它一些DBMS的實(shí)現(xiàn)方式類似。這種方式有優(yōu)點(diǎn)，也有缺點(diǎn)。優(yōu)點(diǎn)就是可以對(duì)任何語(yǔ)句都能正確工作，一些語(yǔ)句的效率更高。主要的缺點(diǎn)就是二進(jìn)制日志可能會(huì)很大，而且不直觀，所以，你不能使用mysqlbinlog來(lái)查看二進(jìn)制日志。
對(duì)于一些語(yǔ)句，基于記錄的復(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的組合，但是，該查詢會(huì)掃描原表的許多行，卻僅返回三條記錄。此時(shí)，基于記錄的復(fù)制效率更高。
    另一方面，下面的語(yǔ)句，基于語(yǔ)句的復(fù)制更有效：
 mysql> UPDATE enormous_table SET col1 = 0;
此時(shí)使用基于記錄的復(fù)制代價(jià)會(huì)非常高。由于兩種方式不能對(duì)所有情況都能很好的處理，所以，MySQL 5.1支持在基于語(yǔ)句的復(fù)制和基于記錄的復(fù)制之前動(dòng)態(tài)交換。你可以通過(guò)設(shè)置session變量binlog_format來(lái)進(jìn)行控制。

3.3、復(fù)制相關(guān)的文件

除了二進(jìn)制日志和中繼日志文件外，還有其它一些與復(fù)制相關(guān)的文件。如下：

(1)mysql-bin.index

服務(wù)器一旦開(kāi)啟二進(jìn)制日志，會(huì)產(chǎn)生一個(gè)與二日志文件同名，但是以.index結(jié)尾的文件。它用于跟蹤磁盤上存在哪些二進(jìn)制日志文件。MySQL用它來(lái)定位二進(jìn)制日志文件。它的內(nèi)容如下(我的機(jī)器上)：

(2)mysql-relay-bin.index

該文件的功能與mysql-bin.index類似，但是它是針對(duì)中繼日志，而不是二進(jìn)制日志。內(nèi)容如下：
.\mysql-02-relay-bin.000017
.\mysql-02-relay-bin.000018

(3)master.info

保存master的相關(guān)信息。不要?jiǎng)h除它，否則，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時(shí)，你可以讓slave扮演其它slave的master。此時(shí)，slave把SQL線程執(zhí)行的事件寫(xiě)進(jìn)行自己的二進(jìn)制日志(binary log)，然后，它的slave可以獲取這些事件并執(zhí)行它。如下：

3.5、復(fù)制過(guò)濾(Replication Filters)

復(fù)制過(guò)濾可以讓你只復(fù)制服務(wù)器中的一部分?jǐn)?shù)據(jù)，有兩種復(fù)制過(guò)濾：在master上過(guò)濾二進(jìn)制日志中的事件；在slave上過(guò)濾中繼日志中的事件。如下：

4、復(fù)制的常用拓?fù)浣Y(jié)構(gòu)

---

復(fù)制的體系結(jié)構(gòu)有以下一些基本原則：
(1)    每個(gè)slave只能有一個(gè)master；
(2)    每個(gè)slave只能有一個(gè)唯一的服務(wù)器ID；
(3)    每個(gè)master可以有很多slave；
(4)    如果你設(shè)置log_slave_updates，slave可以是其它slave的master，從而擴(kuò)散master的更新。

MySQL不支持多主服務(wù)器復(fù)制(Multimaster Replication)——即一個(gè)slave可以有多個(gè)master。但是，通過(guò)一些簡(jiǎn)單的組合，我們卻可以建立靈活而強(qiáng)大的復(fù)制體系結(jié)構(gòu)。

4.1、單一master和多slave

由一個(gè)master和一個(gè)slave組成復(fù)制系統(tǒng)是最簡(jiǎn)單的情況。Slave之間并不相互通信，只能與master進(jìn)行通信。

在實(shí)際應(yīng)用場(chǎng)景中，MySQL復(fù)制90%以上都是一個(gè)Master復(fù)制到一個(gè)或者多個(gè)Slave的架構(gòu)模式，主要用于讀壓力比較大的應(yīng)用的數(shù)據(jù)庫(kù)端廉價(jià)擴(kuò)展解決方案。因?yàn)橹灰狹aster和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復(fù)制的延時(shí)一般都很少很少。尤其是自從Slave端的復(fù)制方式改成兩個(gè)線程處理之后，更是減小了Slave端的延時(shí)問(wèn)題。而帶來(lái)的效益是，對(duì)于數(shù)據(jù)實(shí)時(shí)性要求不是特別Critical的應(yīng)用，只需要通過(guò)廉價(jià)的pcserver來(lái)擴(kuò)展Slave的數(shù)量，將讀壓力分散到多臺(tái)Slave的機(jī)器上面，即可通過(guò)分散單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的讀壓力來(lái)解決數(shù)據(jù)庫(kù)端的讀性能瓶頸，畢竟在大多數(shù)數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)中的讀壓力還是要比寫(xiě)壓力大很多。這在很大程度上解決了目前很多中小型網(wǎng)站的數(shù)據(jù)庫(kù)壓力瓶頸問(wèn)題，甚至有些大型網(wǎng)站也在使用類似方案解決數(shù)據(jù)庫(kù)瓶頸。

如下：

 如果寫(xiě)操作較少，而讀操作很時(shí)，可以采取這種結(jié)構(gòu)。你可以將讀操作分布到其它的slave，從而減小master的壓力。但是，當(dāng)slave增加到一定數(shù)量時(shí)，slave對(duì)master的負(fù)載以及網(wǎng)絡(luò)帶寬都會(huì)成為一個(gè)嚴(yán)重的問(wèn)題。
這種結(jié)構(gòu)雖然簡(jiǎn)單，但是，它卻非常靈活，足夠滿足大多數(shù)應(yīng)用需求。一些建議：
(1)    不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲(chǔ)引擎)；
(2)    用一個(gè)slave作為備用master，只進(jìn)行復(fù)制；
(3)    用一個(gè)遠(yuǎn)程的slave，用于災(zāi)難恢復(fù)；

大家應(yīng)該都比較清楚，從一個(gè)Master節(jié)點(diǎn)可以復(fù)制出多個(gè)Slave節(jié)點(diǎn)，可能有人會(huì)想，那一個(gè)Slave節(jié)點(diǎn)是否可以從多個(gè)Master節(jié)點(diǎn)上面進(jìn)行復(fù)制呢？至少在目前來(lái)看，MySQL是做不到的，以后是否會(huì)支持就不清楚了。

MySQL不支持一個(gè)Slave節(jié)點(diǎn)從多個(gè)Master節(jié)點(diǎn)來(lái)進(jìn)行復(fù)制的架構(gòu)，主要是為了避免沖突的問(wèn)題，防止多個(gè)數(shù)據(jù)源之間的數(shù)據(jù)出現(xiàn)沖突，而造成最后數(shù)據(jù)的不一致性。不過(guò)聽(tīng)說(shuō)已經(jīng)有人開(kāi)發(fā)了相關(guān)的patch，讓MySQL支持一個(gè)Slave節(jié)點(diǎn)從多個(gè)Master結(jié)點(diǎn)作為數(shù)據(jù)源來(lái)進(jìn)行復(fù)制，這也正是MySQL開(kāi)源的性質(zhì)所帶來(lái)的好處。

4.2、主動(dòng)模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master復(fù)制的兩臺(tái)服務(wù)器，既是master，又是另一臺(tái)服務(wù)器的slave。這樣，任何一方所做的變更，都會(huì)通過(guò)復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫(kù)中。

可能有些讀者朋友會(huì)有一個(gè)擔(dān)心，這樣搭建復(fù)制環(huán)境之后，難道不會(huì)造成兩臺(tái)MySQL之間的循環(huán)復(fù)制么？實(shí)際上MySQL自己早就想到了這一點(diǎn)，所以在MySQL的BinaryLog中記錄了當(dāng)前MySQL的server-id，而且這個(gè)參數(shù)也是我們搭建MySQLReplication的時(shí)候必須明確指定，而且Master和Slave的server-id參數(shù)值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后，MySQL就很容易判斷某個(gè)變更是從哪一個(gè)MySQLServer最初產(chǎn)生的，所以就很容易避免出現(xiàn)循環(huán)復(fù)制的情況。而且，如果我們不打開(kāi)記錄Slave的BinaryLog的選項(xiàng)（--log-slave-update）的時(shí)候，MySQL根本就不會(huì)記錄復(fù)制過(guò)程中的變更到BinaryLog中，就更不用擔(dān)心可能會(huì)出現(xiàn)循環(huán)復(fù)制的情形了。

如圖：

主動(dòng)的Master-Master復(fù)制有一些特殊的用處。例如，地理上分布的兩個(gè)部分都需要自己的可寫(xiě)的數(shù)據(jù)副本。這種結(jié)構(gòu)最大的問(wèn)題就是更新沖突。假設(shè)一個(gè)表只有一行(一列)的數(shù)據(jù)，其值為1，如果兩個(gè)服務(wù)器分別同時(shí)執(zhí)行如下語(yǔ)句：
在第一個(gè)服務(wù)器上執(zhí)行：

mysql> UPDATE tbl SET col=col + 1;

在第二個(gè)服務(wù)器上執(zhí)行：

mysql> UPDATE tbl SET col=col * 2;

那么結(jié)果是多少呢？一臺(tái)服務(wù)器是4，另一個(gè)服務(wù)器是3，但是，這并不會(huì)產(chǎn)生錯(cuò)誤。
實(shí)際上，MySQL并不支持其它一些DBMS支持的多主服務(wù)器復(fù)制(Multimaster Replication)，這是MySQL的復(fù)制功能很大的一個(gè)限制(多主服務(wù)器的難點(diǎn)在于解決更新沖突)，但是，如果你實(shí)在有這種需求，你可以采用MySQL Cluster，以及將Cluster和Replication結(jié)合起來(lái)，可以建立強(qiáng)大的高性能的數(shù)據(jù)庫(kù)平臺(tái)。但是，可以通過(guò)其它一些方式來(lái)模擬這種多主服務(wù)器的復(fù)制。

4.3、主動(dòng)-被動(dòng)模式的Master-Master(Master-Master in Active-Passive Mode)

這是master-master結(jié)構(gòu)變化而來(lái)的，它避免了M-M的缺點(diǎn)，實(shí)際上，這是一種具有容錯(cuò)和高可用性的系統(tǒng)。它的不同點(diǎn)在于其中一個(gè)服務(wù)只能進(jìn)行只讀操作。如圖：

4.4 級(jí)聯(lián)復(fù)制架構(gòu) Master –Slaves - Slaves

在有些應(yīng)用場(chǎng)景中，可能讀寫(xiě)壓力差別比較大，讀壓力特別的大，一個(gè)Master可能需要上10臺(tái)甚至更多的Slave才能夠支撐注讀的壓力。這時(shí)候，Master就會(huì)比較吃力了，因?yàn)閮H僅連上來(lái)的SlaveIO線程就比較多了，這樣寫(xiě)的壓力稍微大一點(diǎn)的時(shí)候，Master端因?yàn)閺?fù)制就會(huì)消耗較多的資源，很容易造成復(fù)制的延時(shí)。

遇到這種情況如何解決呢？這時(shí)候我們就可以利用MySQL可以在Slave端記錄復(fù)制所產(chǎn)生變更的BinaryLog信息的功能，也就是打開(kāi)—log-slave-update選項(xiàng)。然后，通過(guò)二級(jí)（或者是更多級(jí)別）復(fù)制來(lái)減少M(fèi)aster端因?yàn)閺?fù)制所帶來(lái)的壓力。也就是說(shuō)，我們首先通過(guò)少數(shù)幾臺(tái)MySQL從Master來(lái)進(jìn)行復(fù)制，這幾臺(tái)機(jī)器我們姑且稱之為第一級(jí)Slave集群，然后其他的Slave再?gòu)牡谝患?jí)Slave集群來(lái)進(jìn)行復(fù)制。從第一級(jí)Slave進(jìn)行復(fù)制的Slave，我稱之為第二級(jí)Slave集群。如果有需要，我們可以繼續(xù)往下增加更多層次的復(fù)制。這樣，我們很容易就控制了每一臺(tái)MySQL上面所附屬Slave的數(shù)量。這種架構(gòu)我稱之為Master-Slaves-Slaves架構(gòu)

這種多層級(jí)聯(lián)復(fù)制的架構(gòu)，很容易就解決了Master端因?yàn)楦綄賁lave太多而成為瓶頸的風(fēng)險(xiǎn)。下圖展示了多層級(jí)聯(lián)復(fù)制的Replication架構(gòu)。

當(dāng)然，如果條件允許，我更傾向于建議大家通過(guò)拆分成多個(gè)Replication集群來(lái)解決

上述瓶頸問(wèn)題。畢竟Slave并沒(méi)有減少寫(xiě)的量，所有Slave實(shí)際上仍然還是應(yīng)用了所有的數(shù)據(jù)變更操作，沒(méi)有減少任何寫(xiě)IO。相反，Slave越多，整個(gè)集群的寫(xiě)IO總量也就會(huì)越多，我們沒(méi)有非常明顯的感覺(jué)，僅僅只是因?yàn)榉稚⒌搅硕嗯_(tái)機(jī)器上面，所以不是很容易表現(xiàn)出來(lái)。

此外，增加復(fù)制的級(jí)聯(lián)層次，同一個(gè)變更傳到最底層的Slave所需要經(jīng)過(guò)的MySQL也會(huì)更多，同樣可能造成延時(shí)較長(zhǎng)的風(fēng)險(xiǎn)。

而如果我們通過(guò)分拆集群的方式來(lái)解決的話，可能就會(huì)要好很多了，當(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)點(diǎn)就是提供了冗余。在地理上分布的復(fù)制結(jié)構(gòu)，它不存在單一節(jié)點(diǎn)故障問(wèn)題，而且還可以將讀密集型的請(qǐng)求放到slave上。

級(jí)聯(lián)復(fù)制在一定程度上面確實(shí)解決了Master因?yàn)樗綄俚腟lave過(guò)多而成為瓶頸的問(wèn)題，但是他并不能解決人工維護(hù)和出現(xiàn)異常需要切換后可能存在重新搭建Replication的問(wèn)題。這樣就很自然的引申出了DualMaster與級(jí)聯(lián)復(fù)制結(jié)合的Replication架構(gòu)，我稱之為Master-Master-Slaves架構(gòu)

和Master-Slaves-Slaves架構(gòu)相比，區(qū)別僅僅只是將第一級(jí)Slave集群換成了一臺(tái)單獨(dú)的Master，作為備用Master，然后再?gòu)倪@個(gè)備用的Master進(jìn)行復(fù)制到一個(gè)Slave集群。

這種DualMaster與級(jí)聯(lián)復(fù)制結(jié)合的架構(gòu)，最大的好處就是既可以避免主Master的寫(xiě)入操作不會(huì)受到Slave集群的復(fù)制所帶來(lái)的影響，同時(shí)主Master需要切換的時(shí)候也基本上不會(huì)出現(xiàn)重搭Replication的情況。但是，這個(gè)架構(gòu)也有一個(gè)弊端，那就是備用的Master有可能成為瓶頸，因?yàn)槿绻竺娴腟lave集群比較大的話，備用Master可能會(huì)因?yàn)檫^(guò)多的SlaveIO線程請(qǐng)求而成為瓶頸。當(dāng)然，該備用Master不提供任何的讀服務(wù)的時(shí)候，瓶頸出現(xiàn)的可能性并不是特別高，如果出現(xiàn)瓶頸，也可以在備用Master后面再次進(jìn)行級(jí)聯(lián)復(fù)制，架設(shè)多層Slave集群。當(dāng)然，級(jí)聯(lián)復(fù)制的級(jí)別越多，Slave集群可能出現(xiàn)的數(shù)據(jù)延時(shí)也會(huì)更為明顯，所以考慮使用多層級(jí)聯(lián)復(fù)制之前，也需要評(píng)估數(shù)據(jù)延時(shí)對(duì)應(yīng)用系統(tǒng)的影響。

5、復(fù)制的常見(jiàn)問(wèn)題

---

錯(cuò)誤一：change master導(dǎo)致的：
     Last_IO_Error: error connecting to master 'repl1@IP:3306' - retry-time: 60  retries

錯(cuò)誤二：在沒(méi)有解鎖的情況下停止slave進(jìn)程：

 mysql> stop slave;

ERROR 1192 (HY000): Can't execute the given command because you have active locked tables or an active transaction

錯(cuò)誤三：在沒(méi)有停止slave進(jìn)程的情況下change master

mysql> change master to master_host=‘IP', master_user='USER', master_password='PASSWD', master_log_file='mysql-bin.000001',master_log_pos=106;

ERROR 1198 (HY000): This operation cannot be performed with a running slave; run STOP SLAVE first

錯(cuò)誤四：A B的server-id相同：
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids;
these ids must be different for replication to work (or the --replicate-same-server-id option must be used on
slave but this does not always make sense; please check the manual before using it).
查看server-id
mysql> show variables like 'server_id';
手動(dòng)修改server-id
mysql> set global server_id=2; #此處的數(shù)值和my.cnf里設(shè)置的一樣就行
mysql> slave start;

錯(cuò)誤五：change master之后，查看slave的狀態(tài)，發(fā)現(xiàn)slave_IO_running 仍為NO
需要注意的是，上述幾個(gè)錯(cuò)誤做完操作之后要重啟mysql進(jìn)程，slave_IO_running 變?yōu)閅es

錯(cuò)誤六：MySQL主從同步異常Client requested master to start replication from position > file size

字面理解：從庫(kù)的讀取binlog的位置大于主庫(kù)當(dāng)前binglog的值

這一般是主庫(kù)重啟導(dǎo)致的問(wèn)題，主庫(kù)從參數(shù)sync_binlog默認(rèn)為1000，即主庫(kù)的數(shù)據(jù)是先緩存到1000條后統(tǒng)一fsync到磁盤的binlog文件中。

當(dāng)主庫(kù)重啟的時(shí)候，從庫(kù)直接讀取主庫(kù)接著之前的位點(diǎn)重新拉binlog，但是主庫(kù)由于沒(méi)有fsync最后的binlog，所以會(huì)返回1236 的錯(cuò)誤。
正常建議配置sync_binlog=1 也就是每個(gè)事務(wù)都立即寫(xiě)入到binlog文件中。

1、在從庫(kù)檢查slave狀態(tài):

偏移量為4063315

2、在主庫(kù)檢查mysql-bin.001574的偏移量位置

mysqlbinlog mysql-bin.001574 >  ./mysql-bin.001574.bak

tail -10 ./mysql-bin.001574.bak

mysql-bin.001574文件最后幾行 發(fā)現(xiàn)最后偏移量是4059237，從庫(kù)偏移量的4063315遠(yuǎn)大主庫(kù)的偏移量4059237，也就是參數(shù)sync_binlog=1000導(dǎo)致的。

3、重新設(shè)置salve

mysql> stop slave;mysql> change master to master_log_file='mysql-bin.001574' ,master_log_pos=4059237;mysql> start slave;

錯(cuò)誤8：數(shù)據(jù)同步異常情況

第一種：在master上刪除一條記錄，而slave上找不到。

Last_Error: Could not execute Delete_rows event on table market_edu.tl_player_task; Can't find record in 'tl_player_task', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.002094, end_log_pos 286434186

解決方法：由于master要?jiǎng)h除一條記錄，而slave上找不到故報(bào)錯(cuò)，這種情況主上都將其刪除了，那么從機(jī)可以直接跳過(guò)。

可用命令：stop slave;   set global sql_slave_skip_counter=1;    start slave;

第二種：主鍵重復(fù)。在slave已經(jīng)有該記錄，又在master上插入了同一條記錄。

Last_SQL_Error: Could not execute Write_rows event on table hcy.t1;
Duplicate entry '2' for key 'PRIMARY',
Error_code: 1062;
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924

解決方法：在slave刪除重復(fù)的主鍵

第三種：在master上更新一條記錄，而slave上找不到，丟失了數(shù)據(jù)。

Last_SQL_Error: Could not execute Update_rows event on table hcy.t1;
Can't find record in 't1',
Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000010, end_log_pos 263

解決方法：把丟失的數(shù)據(jù)在slave上填補(bǔ)，然后跳過(guò)報(bào)錯(cuò)即可。

insert into t1 values (2,'BTV');

stop slave ;set global sql_slave_skip_counter=1;start slave;

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“高性能Mysql主從架構(gòu)的復(fù)制原理及配置示例”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!

文章名稱：高性能Mysql主從架構(gòu)的復(fù)制原理及配置示例
本文路徑：http://muchs.cn/article16/ipgsdg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供用戶體驗(yàn)、網(wǎng)站營(yíng)銷、網(wǎng)站改版、Google、網(wǎng)站收錄、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)