理解MySQL——複製(Replication)

1、複製概述

1.1、複製解決的問題
數據複製技術有以下一些特點：
(1)    數據分佈
(2)    負載平衡(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線程創建的連接：

 行2為處理slave的I/O線程的連接。
在slave上運行該語句：

行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對於基於語句的日誌處理十分方便。
 
但是，基於語句的複製並不是像它看起來那麼簡單，因為一些查詢語句依賴於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文件，內容如下(我的機器上)：

 (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上。