mysql主從複製搭建中幾種log和pos詳解

主從複製是一個老話題了，這裡不就不說主從複製的細節了，重點講下關於show slave status\G 中幾種日誌和位置的區別；

首先截個圖方便講解：

圖中那麼多參數，更重要的是單是*log,*pos就好幾個，怎麼區分呢，各自又代表什麼意義呢？

我們先來講下主從複製的原理：

一、主從原理

Replication 線程

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

要實現 MySQL 的Replication ，首先必須開啟 Master 端的

Binary Log(mysql-bin.xxxxxx)功能，否則無法實現。因為整個複製過程實際上就是Slave從Master端擷取該日誌然後再在自己身上完全 順序的執行日誌中所記錄的各種操作。開啟 MySQL 的 Binary Log 可以通過在啟動 MySQL Server 的過程中使用 “—log-bin” 參數選項，或者在 my.cnf 設定檔中的 mysqld 參數組([mysqld]標識後的參數部分)增加 “log-bin” 參數項。

複製的基本過程如下 ：

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端的bin-log的檔案名稱和位置記錄到master- info檔案中，以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log的哪個位置開始往後的日誌內容，請發給我”

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

簡單來講就是從庫先通過io線程讀取主庫的二進位檔案（Master_Log_File）和位置（Read_Master_Log_Pos）然後緩衝到本地（從程式庫伺服器）的中繼檔案（Relay_Log_File）中並記錄已經讀取到的位置（Relay_Log_Pos），再通過從庫的sql線程去讀取中繼檔案（Relay_Log_File），這個sql線程執行會記錄已經執行到了哪個檔案（Relay_Master_Log_File）和哪個位置（Exec_Master_Log_Pos）。

圖解為：

那中大家肯定會奇怪複製過程很簡單，似乎也沒有用到三種記錄檔啊，只看到了2個；

既然在slave的狀態中顯示了三種記錄檔以及其位置，那麼我們先來看看他們的定義，稍後再做解釋；

二、日誌解釋

l Master_Log_File，Read_Master_Log_Pos 記錄了IO thread讀到的當前master binlog文 件和位置， 對應master的binlog檔案和位置。

l Relay_Log_File，Relay_Log_Pos記錄了SQL thread執行到relay log的那個檔案和位置，對應的是slave上的relay log檔案和位置。

l Relay_Master_Log_File，Exec_Master_Log_Pos記錄的是SQL thread執行到master binlog的檔案和位置，對應的master上binlog的檔案和位置。

看了定義就能更好的理解上面主從複製的過程了。

三、日誌詳解

1.我們看下普通的binlog檔案，通過mysqlbinlog解析出來的文字檔：

我們這裡主要是row方式的binlog。

可以看到，binlog的event語句開始位置就是二進位binlog檔案的位元組位移位置。而且根據上一個event的end_log_pos可以找到下一個event開始的位置，如所示 。

2.我們再看看relay_log，同樣可以用mysqlbinlog工具來解析(不是同一台機器)：

Relay_log和binlog記錄方式基本相同，最大的不同就是end_log_pos記錄的是master的binlog檔案中event的位置，而不是relay log自己event的位置。，上一個event的end_log_pos和下一個relay log event開始的位置不一樣。 

為什麼需要這樣設定？原因很簡單，就是為了方便找到master binlog的位置，在slave上，記錄relay log 下一個event的開始位移意義不大，但是如果記錄了master binlog的位移量，我們就可以在SQL thread中明確我們執行到master的某個binlog的哪個位置了。那麼是哪個binlog列。我們找到relay_log的最前面 .

· IO thread 把所有從master讀到的binlog記錄到本地的binlog中，所以relay log的最後一個event的end log_pos就是Read_Master_Log_Pos

· SQL thread按照transaction來執行，所以Exec_Master_Log_Pos對應relay log中最後一個事務event的end_log_pos，這個位置對應的是master的binlog的位置。

· Relay_Log_Pos 記錄的是SQL thread執行的event在relay log中結束位置，這個才是relay log的位移量。

那麼，從別的伺服器取的從庫資訊來看，我們重新搭建新的從庫只需要的是其中的Relay_Master_Log_File & Exec_Master_Log_Pos。