Seconds_Behind_Master 在 0 和數字 x 之間交替
我在 debian 9 上有一個帶有 mariadb 10.3.10 的從屬伺服器。幾天來，伺服器一直正常工作，Seconds_Behind_Master 始終保持為 0，表明它已正確同步。從昨天開始，Seconds_Behind_Master 開始在 0 和大於 1000 的數字之間交替。我執行 show slave status 並看到： Seconds_Behind_Master: 3893，然後我再次執行它， Seconds_Behind_Master: 0 然後 Seconds_Behind_Master: 3895，它一直在增長和減少。有人可以幫我解決這個問題嗎？
Seconds_behind_master 不能準確衡量複製滯後。它測量 IO 執行緒獲取的最後一個 binlog 事件的時間戳與 SQL 執行緒執行的最後一個 binlog 事件的時間戳之間的差異。
這可能會產生誤導，例如，如果主伺服器有更多的二進制日誌，而副本尚未獲取。如果 master 和 replica 之間的網路對於 binlogs 的速率來說太慢，則 replica 可能會檢查時間戳差異並錯誤地得出結論，它已被趕上。然後IO執行緒又取了一批binlog，突然時間戳差又大了，貌似replica沒趕上。
在我的環境中，當我們看到這種情況發生時，往往會在網路降級時影響到跨國複製鏈路。
如果 master 正在以基於 ROW 的 binlog 格式向 binlogs 寫入大量大容量內容，也會發生這種情況。一個很好的例子是一個數據庫，它的記錄包含大量的 BLOB/TEXT 內容，但它會快速更新同一行的另一列。預設情況下，基於 ROW 的 binlog 會將整行寫入 binlog，即使是您未更改的列。所以對列的簡單更新
status可能會導致許多兆字節被寫入二進制日誌，並導致跨國家連結的傳輸延遲。副本盡可能快地下載二進制日誌事件，但如果大量二進制日誌事件不斷到達，它自然會在“我已經趕上”和“我落後了”之間切換。
解決方法：在master上設置binlog_row_image=MINIMAL。這會導致基於 ROW 的二進制日誌僅儲存已更改的列。
如果您想獲得更準確的複制延遲度量，請使用心跳工具，如pt-heartbeat。
它發生了（並且從 MySQL 4.0 開始就發生了）；病因和治療方法不明。它很可能會消失。然後復發。等等。