在 MySQL 部署架構選型上，許多公司都會用到主從讀寫分離的架構，如下是一個一主一從的架構，主庫master負責寫入，從庫slave進行讀取。

圖片

但是既然是讀寫分離，必然會面臨這樣一個問題，當在主庫上進行更新后，有可能數據還沒來得及同步到從庫，但是這個時候又有讀數據的需求，為了能正確讀取出數據，這個時候就只有讀主庫了。但是這樣做增加了主庫的壓力，違反了我們做讀寫分離的初衷。所以這一節我們就來針對這種情況探討下，如何盡量的避免對主庫的壓力，盡量的從從庫讀取數據。

主從復制的原理

在探討解決方案前，我們先要對主從復制的原理有所了解，數據庫的操作都會記錄到binlog，如下圖所示，

圖片

1，從數據庫(slave)會啟動兩個線程io_thread 和sql_thread ，通過io_thread將自身與主數據庫(master)建立連接。

2，slave向master發出要同步的位置信息（包含同步的文件名和偏移量），表示需要從該位置發起同步。

3，主數據庫master 將位置點后的binlog發送給slave，  slave獲取到本地形成relay log(中轉日志)。

4， 接著通過sql_thread解析relay log，執行sql。

從主從復制的過程可以看出，主從延遲時間是  在主庫master執行sql的時間點到從庫通過解析relay log 執行sql后的時間點之間的差值。如果應用程序能夠在master寫入數據后等待這么一段時間，再去slave讀取，就能正確的讀取出來數據了。

但是這個時間差值是不確定的，究竟應用程序需要等待多久才去讀取slave，就成了我們需要思考??的問題。

如何避免延遲期間的主從數據不一致

比起在寫入數據后讀取主庫或者寫入數據后sleep一段時間讀取從庫，我給出兩個我覺得比較靠譜點的方法。

判斷位點是否同步

第一種方法是通過等待slave  將master寫入數據后的 binlog的位點同步完成再對slave進行讀取。

每次修改型sql的執行會將master的binlog 的位點(日志偏移量)前移，如果在修改型sql執行完成后，能夠獲取到master的binlog 位點，并且在客戶端阻塞等待slave同步該位點完畢，再從slave讀取就可以了。

MYSQL中提供了一個函數select master_pos_wait(file, pos[, timeout]) 用于在slave上執行等待master節點上的位點同步完成，其中file，和pos是在master上的文件和位點，timeout 為了讓master_pos_wait 函數在timeout秒內沒有返回，則會直接觸發超時返回。

返回結果解析，

• 返回結果正常情況下是一個大于0的整數，表示從pos位點開始完成了多少個事務。
• 如果直接返回結果0，則說明在執行select master_pos_wait(file, pos[, timeout]) 時，位點已經同步完成。
• 如果觸發超時則返回-1。
• 如果執行期間slave發生錯誤，則返回NULL。

所以，在判斷是否應該在寫入數據后讀從庫的邏輯，我們可以這樣來寫，

1， 在master寫入數據后立馬執行 show master status，可以獲取如下結果

圖片

Pasted image 20240308162704.png

可以看到master的binlog文件名稱以及位點。

2， 在slave上執行 select master_pos_wait('mysql-bin.232011',3129472,1);，如果1s內沒有返回，則直接返回-1。

圖片

3， 在上一步如果觸發超時返回返回-1，則直接讀取主庫，如果是>=0 的值，則直接讀取從庫。

這樣便能最大程度從從庫讀取數據。

判斷GTID 是否同步

接著，我們來看下第二種方式，其實第二種方式和通過位點的方式類似，不同的是slave判斷是否將數據同步完成的依據是看GTID的值。

什么是GTID值？

GTID 的全稱是 Global Transaction Identifier，全局事務 ID，是一個事務在提交的時候生成的，是這個事務的唯一標識。

MYSQL開啟 GTID 模式的方式是 在啟動一個 MySQL 實例的時候，加上參數 gtid_mode=on 和 enforce_gtid_cnotallow=on 。

每個事務是和GTID 值一一對應的，每個MYSQL實例會維護一個GTID 集合，來表示實例執行過的事務。

在slave節點上，通過show slave status 可以看到 GTID集合，如下圖所示，

圖片

Pasted image 20240308165622.png

• Auto_Positinotallow=1 ，表示這對主備關系使用了 GTID 協議。
• Retrieved_Gtid_Set，是備庫收到的所有日志的 GTID 集合。
• Executed_Gtid_Set，是備庫所有已經執行完成的 GTID 集合。

如果Executed_Gtid_Set 等于Retrieved_Gtid_Set 說明slave將從master那里獲取到的binlog全部執行完畢。

在master節點執行 show master status，也能看到GTID集合，Executed_Gtid_Set 為master節點執行過的GTID集合。如下圖所示，

圖片

GTID 模式下判斷同步的步驟

在GTID 模式下，從庫slave從主庫master取binlog的邏輯將不再是直接告訴master 要取的文件和位點了，而是由slave將自身的GTID集合告訴master。

master再結合自身的GTID集合，找出在master中有但是在slave中沒有的GTID集合，然后從binlog中找到第一個不在GTID集合中的事務，從該事務的binlog位點開始，往后讀取binlog發送給slave。

MYSQL針對于GTID同樣提供 了一個函數select wait_for_executed_gtid_set(gtid_set, 1);  來讓slave去判斷對master執行過的gtid_set 是否已經同步完成。

wait_for_executed_gtid_set 函數的返回結果解析如下，

• 如果slave 執行的事務中包含傳入的 gtid_set，返回 0。
• 如果等待1s后還沒同步完成，則返回1。

所以在GTID 模式下的，在判斷是否應該在寫入數據后讀從庫的邏輯，我們可以這樣來寫，

1， 在master寫入數據后立馬執行 show master status，可以獲取如下結果

圖片

可以看到master的Executed_Gtid_Set的值。

2， 在slave上執行

select wait_for_executed_gtid_set('76cd5ea1-c541-11ee-87ef-fa163eefe144:1-56382789,  
808d2fb8-687b-11ec-b8b9-fa163e410530:1-144078103,  
9081c19b-63de-11ed-9755-fa163eb8b97f:1-1093294115', 1);

，如果1s內沒有返回，則直接返回1。

圖片

3， 在上一步如果觸發超時即返回1，則直接讀取主庫，如果是=0 ，則直接讀取從庫。這樣便能最大程度從從庫讀取數據。