理解MySQL——複製(Replication)

1、複製概述

1.1、複製解決的問題
資料複製技術有以下一些特點：
(1)    資料分布
(2)    Server Load Balancer(load balancing)
(3)    備份
(4)    高可用性(high availability)和容錯

1.2、複製如何工作
從高層來看，複製分成三步：
(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線程從中繼日誌讀取事件，更新slave的資料，使其與master中的資料一致。只要該線程與I/O線程保持一致，中繼日誌通常會位於OS的緩衝中，所以中繼日誌的開銷很小。
此外，在master中也有一個背景工作執行緒：和其它MySQL的串連一樣，slave在master中開啟一個串連也會使得master開始一個線程。複製過程有一個很重要的限制——複製在slave上是序列化的，也就是說master上的並行更新操作不能在slave上並行操作。

 

2、體驗MySQL複製
MySQL開始複製是很簡單的過程，不過，根據特定的應用情境，都會在基本的步驟上有一些變化。最簡單的情境就是一個新安裝的master和slave，從高層來看，整個過程如下：
(1)在每個伺服器上建立一個複製帳號；
(2)配置master和slave；
(3)Slave串連master開始複製。

2.1、建立複製帳號
每個slave使用標準的MySQL使用者名稱和密碼串連master。進行複製操作的使用者會授予REPLICATION SLAVE許可權。使用者名稱的密碼都會儲存在文字檔master.info中。假如，你想建立repl使用者，如下：
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.*
-> TO repl@'192.168.0.%' IDENTIFIED BY 'p4ssword';

2.2、配置master
接下來對master進行配置，包括開啟二進位日誌，指定唯一的servr ID。例如，在設定檔加入如下值：
[mysqld]
log-bin=mysql-bin
server-id=10
重啟master，運行SHOW MASTER STATUS，輸出如下：

 

 

2.3、配置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.4、啟動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表明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的I/O和SQL線程都已經開始運行，而且Seconds_Behind_Master不再是NULL。日誌的位置增加了，意味著一些事件被擷取並執行了。如果你在master上進行修改，你可以在slave上看到各種記錄檔的位置的變化，同樣，你也可以看到資料庫中資料的變化。

你可查看master和slave上線程的狀態。在master上，你可以看到slave的I/O線程建立的串連：

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、從另一個master初始化slave
前面討論的假設你是新安裝的master和slave，所以，slave與master有相同的資料。但是，大多數情況卻不是這樣的，例如，你的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對於基於語句的Tlog十分方便。
 
但是，基於語句的複製並不是像它看起來那麼簡單，因為一些查詢語句依賴於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 0 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進行通訊。如下：

 如果寫操作較少，而讀操作很時，可以採取這種結構。你可以將讀操作分布到其它的slave，從而減小master的壓力。但是，當slave增加到一定數量時，slave對master的負載以及網路頻寬都會成為一個嚴重的問題。
這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：
(1)    不同的slave扮演不同的作用(例如使用不同的索引，或者不同的儲存引擎)；
(2)    用一個slave作為備用master，只進行複製；
(3)    用一個遠端slave，用於災難恢複；
4.2、主動模式的Master-Master(Master-Master in Active-Active Mode)
Master-Master複製的兩台伺服器，既是master，又是另一台伺服器的slave。

主動的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-Master結構(Master-Master with Slaves)
這種結構的優點就是提供了冗餘。在地理上分布的複製結構，它不存在單一節點故障問題，而且還可以將讀密集型的請求放到slave上。

 

主要參考：《High Performance MySQL》