MySQL的復制及各種高可用架構，基本都是基於主從復制的組合。而主從復制是基於binary log的，

這裏就詳細介紹下基於binary log event（二進制日誌事件）復制的原理。

主從復制有實現兩種方法:傳統復制方式（基於server_id）和GTID（全局事務ID）.（MySQL5.6以後支持）

二、原理詳解

1.簡單來說（三個線程三個步驟）:

1）主服務器Master將數據庫的改變寫入二進制日誌文件，並維護一個等待從服務器連接的線程binlog_dump；

2）從服務器Slave會啟動一個線程(IO Thread)和主服務器Master的binlog_dump線程建立連接，然後將數據

讀取到從服務器Slave，並寫入中繼日誌（Relay log）；

3）從服務器Slave另一個線程（SQL thread）會從中繼日誌中讀取數據，並在從數據庫應用更新，完成數據同步。

2.細節實現：

　　MySQL使用3個線程來執行復制功能（一個在主服務器，兩個在從服務器）。

1）當從服務器發出start slave時，從服務器Slave創建一個I/0線程，去連接主服務器Master並讓他發送記錄在其二進制日誌中的語句。

2）主服務器Master創建一個線程Binlog Dump將二進制日誌中的內容發送到從服務器Slave。（可在show processlist中看到該線程）

3）從服務器Slave I/O線程讀取主服務器Binlog Dump線程發送過來的內容並將數據拷貝到從服務器數據目錄中的中繼日誌中Relay log。

4）從服務器Slave創建SQL線程，用於讀取中繼日誌並執行日誌中包含的更新。

在從服務器上讀取和執行更新語句被分成兩個獨立的任務，當從服務器啟動時，其I/O線程可以很快地從主服務器Master索取所有

二進制日誌內容，同時交由SQL線程來更新應用到從庫（會有點慢）。

3.復制線程的狀態

　　通過show processlist可以看到三個線程的狀態，show slave status 可以看到IO、SQL線程的狀態。常見的狀態有：

1）主服務器Binlog Dump線程狀態：

Master has sent all binlog to slave; waiting for binlog to be updated

線程已經從二進制日誌中讀取所有主要的更新並已經發送到從服務器。

線程現在正空閑，等待由主服務器上新的更新導致的出現在二進制日誌文件中新的事務。

2）從服務器I/O線程狀態：

Waiting for master to send event

線程已經連接上主服務器，正在等待二進制日誌事件到達。如果主服務器正空閑，會持續較長時間。

如果等待持續slave_net_timeout秒，則發生超時。此時，線程認為連接中斷並企圖重新連接。

3）從服務器SQL線程狀態：

Reading event from the relay log

線程已經從中繼日誌中讀取一個事件，可以對事件進行處理了。

Slave has read all relay log;waiting for the slave I/O thread to update it

線程已經處理了中繼日誌文件中的所有事件，現在正在等待I/O線程將新事件寫入中繼日誌。

4.復制過程中狀態的保持：

　　從服務器通過在my.cnf設置如下參數，將主從狀態保存在mysql庫的表中slave_master_info、slave_relay_log_info。

下次從服務器啟動時，讀取這個表來確定它已經從主服務器讀取了多少二進制日誌，已經自己處理裝機日誌的程度。

relay_log_info_repository = TABLE
master_info_repository = TABLE

MySQL主從復制原理