MySQL Replication 線程(理解詳細過程)

標籤：避免   數值   開始   檔案名稱   ace   relay   一點   過程   操作   

Replication 線程

Mysql 的Replication 是一個非同步複製過程，從一個Mysql instace（我們稱之為Master）複製到另一個Mysql instance（我們稱之Slave）。在Master 與Slave 之間的實現整個複製過程主要由三個線程來完成，其中兩個線程（Sql 線程和IO 線程）在Slave 端，另外一個線程（IO 線程）在Master 端。


要實現MySQL 的Replication ，首先必須開啟Master 端的Binary Log（mysqlbin.xxxxxx）功能，否則無法實現。因為整個複製過程實際上就是Slave 從Master 端擷取該日誌然後再在自己身上完全順序的執行日誌中所記錄的各種操作

MySQL 複製的基本過程如下：
1. Slave 上面的IO 線程串連上Master，並請求從指定記錄檔的指定位置（或者從最開始的日誌）之後的日誌內容；
2. Master 接收到來自Slave 的IO 線程的請求後，通過負責複製的IO 線程根據請求資訊讀取指定日誌指定位置之後的日誌資訊，返回給Slave 端的IO 線程。返回資訊中除了日誌所包含的資訊之外，還包括本次返回的資訊在Master 端的Binary Log檔案的名稱以及在Binary Log 中的位置；
3. Slave 的IO 線程接收到資訊後，將接收到的日誌內容依次寫入到Slave 端的Relay Log 檔案(mysql-relay-bin.xxxxxx)的最末端，並將讀取到的Master 端的binlog的檔案名稱和位置記錄到master-info 檔案中，以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log 的哪個位置開始往後的日誌內容，請發給我”

4. Slave 的SQL 線程檢測到Relay Log 中新增加了內容後，會馬上解析該Log 檔案中的內容成為在Master 端真實執行時候的那些可執行檔Query 語句，並在自身執行這些Query。這樣，實際上就是在Master 端和Slave 端執行了同樣的Query，所以兩端的資料是完全一樣的。

 

可能有些讀者朋友會有一個擔心，這樣搭建複製環境之後，難道不會造成兩台MySQL 之間的迴圈複製嗎？

　　　　實際上MySQL 自己早就想到了這一點，所以在MySQL 的Binary Log 中記錄了當前MySQL 的server-id，而且這個參數也是我們搭建MySQL Replication 的時候必須明確指定，而且Master 和Slave 的server-id 參數值比需要不一致才能使MySQLReplication 搭建成功。一旦有了server-id 的值之後，MySQL 就很容易判斷某個變更是從哪一個MySQL Server 最初產生的，所以就很容易避免出現迴圈複製的情況。而且，如果我們不開啟記錄Slave 的Binary Log 的選項（--log-slave-update）的時候，MySQL 根本就不會記錄複製過程中的變更到Binary Log 中，就更不用擔心可能會出現迴圈複製的情形了。

 

MySQL Replication 線程(理解詳細過程)