MySQL主從複製

　　在MySQL主從複製過程當中，會有兩個角色，master和slave，數據流向是從master到slave。單個主機的數據庫服務器缺乏健壯性，當主機出現故障後，數據庫沒法正常對外提供服務，對應用來是不可避免。因此這個時候須要提升數據庫系統的健壯性，主從複製replication，是將master主機上指定數據庫的變化，記錄在指定的binlog文件中，slave主機經過讀取master主機的binlog文件，將變化的數據，寫入到slave主機的本地數據庫中。實現數據庫的備份。

　　MySQL數據庫的主從複製，是一個異步的過程，也就是說master庫的寫操做，和slave庫的複製操做，並無關係，能夠徹底剝離開。

　　實現了MySQL數據庫的主從複製以後，這個時候就帶出一個更好的優點，不只能對master數據庫服務器進行數據備份，還能作讀寫分離，因爲主從複製的特殊性，全部的更新數據庫的操做，都必須在master主機上進行，避免在slave主機上操做後，致使主從複製的結果不一致，slave主機上保留的，是master主機的徹底副本，因此這個時候，對應用來講，全部的讀操做，就能夠放在slave主機上。相比於以前，同一臺數據庫服務器上，既進行數據庫寫操做，又進行數據庫讀操做，開啓主從複製以後，能夠規劃應用，寫操做只在master主機上，將全部的讀操做，分擔到全部的slave主機上，這就減輕了master主機的壓力，同時，也提高了數據庫讀寫的性能。

　　主從複製的三個線程：

　　一、master主機的IO線程,Binlog dump thread

　　一旦要開啓主從複製，master主機上必需要制定一個二進制文件的位置，也就是binlog文件位置，在binlog文件中，記錄了master數據庫的變化，在master數據庫變化的時候，一方面，master數據庫將IO寫操做，寫入到本地數據庫中data，同時，經過這個IO線程，記錄master數據庫的變化，將變化的內容，寫入到二進制文件中。

　　該IO線程，還做爲服務端，處理slave主機發過來的請求，在slave主機發過來的IO請求中，包含了幾個關鍵因素：用戶名/密碼，binlog_file文件和位置position，其中用戶名/密碼是在master主機上建立的，而且分配了指定數據庫的replication權限的，用戶對slave主機進行鑑權；binlog_file文件名和position是用來肯定slave主機須要從哪裏開始讀取更新變化。根據slave主機發來的請求，該IO線程，會去指定的binlog_file和位置position，讀取現有的更新內容，發送給slave端。同時還會將讀取以後的新的binlog_file和位置position發送給slave主機。

　　show processlist，查看。

　　該線程向在讀取master主機上binlog文件時，須要添加一個鎖，當數據內容被讀取以後，該鎖就釋放了，數據內容讀取出來以後，就會由該線程發給slave。而鎖的釋放，有多是在數據發送給slave以前。

　　二、slave主機的IO線程

　　slave主機經過該IO線程，向master主機請求binlog日誌文件，請求時會帶上用戶名/密碼，binlog_file和位置position，接收到master主機的反饋後，master主機會反饋兩部份內容，數據庫binlog文件，和新的binlog_file和position位置，該IO線程會將數據庫binlog文件內容，寫入到本身的relay_log中，以增長的方式，同時將新的master主機的binlog_file和位置position寫入到本身的master.info文件中，直接覆蓋。master主機的屬性、本身的用戶名/密碼、binlog_file和position都是slave主機設置的，一旦開啓了主從同步，會自動生成master.info文件，每同步一次，該master.info文件就會更新一次。

　　當slave主機上啓用了start slave以後，就會建立這個IO線程，這個線程會鏈接到master主機上，請求master主機binlog中的更新。

　　該IO線程，會讀取master主機發送回來的更新，而後複製到本地文件中，組成本身的relaylog

　　經過show slave status中SLAVE io running，能夠看到該線程的狀態。

　　三、slave主機的SQL線程

　　slave主機的SQL線程，會時時監控slave主機的relay_log文件，當發現relay_log中有增長內容時，會將讀取內容，還原成master主機上執行過的SQL操做，寫入到本地的數據庫中。

 　　在一個主從複製組group中，有3個線程，其中master上只會有一個bin log dump線程，每個slave主機上，都會有兩個線程。

　　在slave主機上，2個線程分開處理，1個從master上去讀取binlog，1個在本地執行，這是兩個分別獨立的任務，這兩個任務之間也不會有什麼影響，IO線程慢，不會影響SQL線程。好比，當slave主機中止複製了一段時間，當slave主機啓動開始複製周，IO線程會從master主機上抓取全部的binlog信息，無論SQL線程處理了多少。當SQL線程尚未徹底將IO線程抓取的binlog信息內容徹底處理時，slave主機中止了，這個時候數據也不會丟失，由於IO線程已經獲取了全部的binlog，而且存放到本身的本地relaylog中，當下一次slave主機啓動時，繼續執行SQL線程，這也方便master主機清理本身的binlog，一旦slave獲取了binlog內容，master主機就會清理了。

　　master主機上的線程

　　

　　slave上的線程

　　

 　　在數據複製過程當中，slave上會生成多個日誌文件，用來保存從master主機上獲取的binlog信息，如今的狀態，以及出列到relaylog中的位置，主要有三種：

　　一、relay log中的內容，是從master的binlog中讀取的信息，由slave的IO線程寫入，在relay log中的事件event，會被SQL線程執行

　　二、master info log，會記錄slave主機鏈接的master主機的狀態信息和當前的配置信息，包含master主機名，登陸憑據，以及slave主機已經讀取到的位置

　　三、relay log info，記錄了SQL線程執行了relay log中的位置。

 

　Relay log

　　relay log和binlog相似，包含了大量了描述數據庫變動的文件，同時包含一個索引文件，該索引文件是全部使用過的relay log的名稱。

　　relay log文件，指的是包含許多描述數據庫變動的事件，而relay log，則是relay log文件和索引。

　　relay log文件，和binlog有相同的格式，能夠經過mysqlbinlog來讀取。默認狀況下，relaylog文件存放在data目錄中，命名格式是hostname-relay-bin.****,hostname是主機名，××××是序列號，序列號是連續的，連續的日誌文件都是經過連續的序列號產生的，slave會用一個index索引文件，來跟蹤當前使用的relay log文件，默認的索引文件也是在data目錄中顯示。默認狀況下，relay log文件和index文件，都是連續產生的，也能夠經過設置服務器屬性，來直接覆蓋。

　　若是slave主機使用的是基於主機名的命名方式，來命名relaylog文件，當修改了slave主機的主機名後，會產生問題，致使複製失敗，Failed to open the relay log and Could not find target log during relay log initialization。爲了不出現這樣的問題，在初始化配置slave主機的時候，能夠經過屬性來設置relay log和index的命名。這就使得命名和主機名獨立開來。

　　當SQL執行了relay log以後，會自動刪除，由於已經執行了，也就不在須要這些文件了，

 

　　master.info文件和relay-log.info文件存儲在硬盤上，當slave主機從新啓動時，經過讀取這兩個文件，就能知道須要從master的binlog的何處開始讀取binlog內容，以及須要從本身的relay-log的何處開始執行。其中，master.info文件是由slave上的IO線程負責更新的，relay-log.info文件是由SQL線程負責更新。

　　這是slave上的master.info文件，一次顯示的是文件中行數、master的binlog文件、位置、master主機名、用戶、密碼、端口、重複次數。

　　而relay-log.info中顯示了4行，relay log文件，位置，從master的讀取的binlog文件名，slave上已經執行的位置（若是已經複製完成，後兩行，應該和master上show master status內容一致）

　　

　　若是slave複製在進行，直接經過show slave status就能夠看到狀態，若是沒有運行，就須要看文件了。

 

　　主從複製的4中架構演變

1. 一主一從，主機負責寫，從機負責讀
2. 一主多從，防止從機故障，影響讀操做
3. 多級主從，防止主機故障，影響寫操做
4. multi-source

 　　在一主多從中，一個master主機，下掛了多個slave從機，當master主機出現故障時，slave主機也就沒法執行寫操做，因此要對master主機進行保護，這個時候，能夠考慮master主機作一個雙主從服務，舉個例子，兩臺主機A和B，A便是B的master主機，也是B的slave從機，保證不管是從A上面寫仍是從B上寫，都可以實現AB數據的一致性。

　　當有了兩個主機以後，主機下掛的從機，就須要對兩個主機進行同步，若是有4臺主機A、B、C、D，其中AB互爲主從，AC爲主從，BD爲主從，當在A上發生數據修改，則BC都能同步，可是D沒法同步，由於D同步的是B的binlog，而B同步的是A的binlog，在B上面是relaylog，並無寫入到binlog中，因此D也就沒法同步數據。就是由於這種狀況，因此全部的從機，須要對全部的主機進行同步，也就是所謂的multi-source，實際上就是添加多個change master to ，結尾是for channel ""，爲這個master起一個名字，就行了。

CHANGE MASTER TO
 MASTER_HOST='192.168.64.132',
 MASTER_PORT=3307,
 MASTER_USER='replication',
 MASTER_PASSWORD='123456',
 MASTER_LOG_FILE='mysqlbin.000012',
 MASTER_LOG_POS=319 for channel 'mastera';
 
CHANGE MASTER TO
 MASTER_HOST='192.168.64.129',
 MASTER_PORT=3307,
 MASTER_USER='replication',
 MASTER_PASSWORD='123456',
 MASTER_LOG_FILE='mysqlbin.000015',
 MASTER_LOG_POS=2262 for channel 'masterb';
 
在slave的配置文件中增長
master_info_repository=TABLE;
relay_log_info_repository=TABLE;


或者在啓動以後，設置全局系統變量
STOP SLAVE;
SET GLOBAL master_info_repository = 'TABLE'; 
SET GLOBAL relay_log_info_repository = 'TABLE';

　　當實現了multi-source以後，就可以保證任何主節點的數據修改，都會同步到全部的從節點中。實現了數據的一致性。