理解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通知儲存引擎提交事務。
SQL slave thread處理該過程的最後一步。SQL執行緒從中繼日誌讀取事件，更新slave的資料，使其與master中的資料一致。只要該執行緒與I/O執行緒保持一致，中繼日誌通常會位於OS的快取中，所以中繼日誌的開銷很小。
2、體驗MySQL複製
MySQL開始複製是很簡單的過程，不過，根據特定的應用場景，都會在基本的步驟上有一些變化。最簡單的場景就是一個新安裝的master和slave，從高層來看，整個過程如下：
(1)在每個伺服器上建立一個複製帳號；
(2)配置master和slave；
(3)Slave連線master開始複製。
2.1、建立複製帳號
每個slave使用標準的MySQL使用者名稱和密碼連線master。進行復制操作的使用者會授予REPLICATION SLAVE許可權。使用者名稱的密碼都會儲存在文字檔案master.info中。假如，你想建立repl使用者，如下：
-> TO [email protected]'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對於基於語句的日誌處理十分方便。
但是，基於語句的複製並不是像它看起來那麼簡單，因為一些查詢語句依賴於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用它來定位二進位制日誌檔案。它的內容如下(我的機器上)：
轉載於:https://blog.51cto.com/jinjiang2009/1342178