Mysql 的主從延遲 指的是 主庫受寫入 后 到這個寫入能體現在 從庫上 的這段時間

Mysql 的主從延遲 有兩個原因：

1. 寫操作 已經在 主庫中執行了，但是 binlog 還沒有發送出去， 后者還在路上，沒有被 從庫收到

2. 雖然 binlog 已經被 從庫接收到了，但是仍然是以 relay log 存在，還沒有被從庫消化

對于消費之后要馬上顯示余額這種對數據一致性強的金融業務，無奈的辦法是讀和寫都打到 主庫上。這就需要拆庫拆表，分散壓力。

如果實時性不強，比如說評論，點贊之類的，可以先使用 前端的 Ajax 直接在用戶的界面上 顯示出對應的操作結果，不必讀剛剛提交的評論或點贊，用戶可能刷新界面，刷新界面才是真正的去讀取

此時大概率寫入的數據已經在從庫中了(前提是機器工作正常)

要消除 1 的影響的話，就要在主從間采取類似 request - ack 方式的 問答式交互，類似于 HDFS 的 客戶端和流水線的問答方式。但是 Mysql 只支持 一主一從

Mysql 5.5 的 semi-sync 支持這種功能。

要消除 2 的影響的話，可以讓從庫等待 seconds_behind_master = 0 , 表示消耗完主庫發來的 binlog，但是只能精確到秒級，真正地要精確到語句的話，要等待本庫消耗的位點等待

也就是不用 GTID 的情況下，要保證執行完的 binlog 的位點 要達到 收到的 binlog 的位點

如果是采用GTID 的情況下，要保證執行完的? binlog 的 GTID 的集合 要 到達收到的 GTID 集合

但是，上面兩種消除，都是不必要的，因為都是在等待主從的整個狀態 完全一致，追求的是 主從數據庫之間完全沒有延遲，可能我們寫入 A ，想讀取 A， 只用A 同步到 從庫就行了。

但是如果 后來 寫庫上又有寫語句，并且不能及時同步到從庫。那么根據上面的消除策略，就一直讀不到 A ，即使 A 已經在從庫上了。

于是我們想要 得到 寫入的 A 在日志中的位點，或者 GTID 。

要去從庫讀取 A 的時候，可以等待 A 同步到 從庫再開始讀，Mysql 官方給出了對應的兩種實現：兩種原理都差不多

1.不使用 GTID :

先在主庫上使用?show master status 得到寫入A后 ，主庫的最新 binlog 的位點

然后在從庫上使用?select master_pos_wait(File, Position, 1)； 表示等待 binlog 文件 File ， 并且等待這個 binlog 文件的 Position 位點 同步到從庫，1表示超時時間

2.使用 GTID:

獲得 A 對應的 GTID 有兩種方式，一種和上面一樣，使用 show master status。二是使用官方的 API ，具體是 C 實現，對于 Java 可以用 JNI 嵌入到 JVM 中去，官方的 API 允許執行后直接返回 這條語句對應 的 GTID。

然后在從庫上使用?select wait_for_executed_gtid_set(gtid1, 1)；表示等待 gtid1 同步到 從庫，超時時間1 秒

有時候 JDBC 的數據庫鏈接長時間不用之后 會斷開，是因為兩個過期參數：

interactive_timeout，wait_timeout

這兩個參數 都是控制 數據庫客戶端 和 數據庫 不交互多久之后 斷開連接

只不過前一個是 在指定了 對應的參數的時候才用的。一般使用 后面的？需要試驗證實

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_wait_timeout

總結

以上是生活随笔為你收集整理的mysql从盘延迟_Mysql-主从延迟解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。