主從複製是一個老話題了，這裏不就不說主從複製的細節了，重點講下關於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。