一主多從模式下的讀寫分離方案設計

在一主多從的環境下，由於同步的問題，會出現主庫記錄已更改，從庫尚未收到binlog或者尚未應用binlog的情況，這時如果我們在從庫上讀取該記錄，會讀取到以前的資料，稱之為「過期讀」，對於有的業務來說這是不允許的，所以從程式的角度，在程式應用讀寫分離時，需要考慮到這個因素。

強制走主庫方案：

對於那些對實時性要求比較高的業務查詢請求，將其分配給主庫，實時性要求低的分配給從庫。

有點"取巧"的意思，且受業務限制比較大。

判斷主備無延遲方案：

1)通過seconds_behind_master判斷(精度存疑)

2)對比位點判斷

master_log_file和read_master_log_pos表示的是讀取到主庫的最新位點，relay_master_log_file和exec_master_log_pos表示的是備庫執行到的最新位點

如果這兩組值完全相同，則表明接收到的日誌已經同步完成

3)對比gtid判斷

auto_position=1表明主備使用的是gtid協議。

retrieved_gtid_set表示的是備庫收到的gtid的集合，executed_gtid_set表示的是備庫執行完成的gtid的集合

如果這兩個集合相同，則表明接收到的日誌已經同步完成

semi_sync:

為了處理那種主庫事務已經執行提交返回客戶端，從庫還未收到binlog的場景。

semi_sync的思路:

1.事務提交的時候，主庫把binlog發給從庫

2.從庫收到binlog後，傳送給主庫乙個ack，表示收到

3.主庫在收到ack後，返回給客戶端"事務完成"的資訊(如果是一主多從的話，主庫收到任意從庫返回的ack後就給客戶端返回確認)

等主庫位點方案：

select master_pos_wait(file, pos[,timeout]);

在從庫執行，引數file和pos指的是主庫上的檔名和位置，timeout可以選，設定為正整數n表示這個函式最多等待n秒。

函式正常返回的話，是乙個正整數m，表示從庫從執行命令開始到應用完file和pos表示的binlog的位置，共執行的事務數。如果返回0則表示命令執行時該binlog已執行過。如果等待超時，返回-1

等gtid方案:

select wait_for_executed_gtid_set(gtid_set[,timeout]);

在從庫執行，等待，直到從庫執行的事務中包含傳入的gtid_set，返回0。超時返回1。

由於從mysql 5.7.6開始，事務的gtid可以直接從返回包中獲取到，所以主庫在執行完事務之後不需要再去主庫上查詢來定位事務

引數session_track_gtids設定為own_gtid，然後可以通過api介面mysql_session_track_get_first從返回包中解析gtid