共計 3231 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章主要講解了“MySQL 主從數據庫同步延遲問題怎么解決”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“MySQL 主從數據庫同步延遲問題怎么解決”吧！
MySQL 的主從同步是一個很成熟的架構，優點為：
①在從服務器可以執行查詢工作(即我們常說的讀功能)，降低主服務器壓力;
②在從主服務器進行備份，避免備份期間影響主服務器服務;③當主服務器出現問題時，可以切換到從服務器。
相信大家對于這些好處已經非常了解了，在項目的部署中也采用這種方案。但是 MySQL 的主從同步一直有從庫延遲的問題，那么為什么會有這種問題。這種問題如何解決呢？
鴻蒙官方戰略合作共建——HarmonyOS 技術社區
MySQL 數據庫主從同步延遲原理。
MySQL 數據庫主從同步延遲是怎么產生的。
MySQL 數據庫主從同步延遲解決方案。
1. MySQL 數據庫主從同步延遲原理。
答：談到 MySQL 數據庫主從同步延遲原理，得從 mysql 的數據庫主從復制原理說起，mysql 的主從復制都是單線程的操作，主庫對所有 DDL 和 DML 產生 binlog，binlog 是順序寫，所以效率很高，slave 的 Slave_IO_Running 線程到主庫取日志，效率很比較高，下一步， 問題來了，slave 的 Slave_SQL_Running 線程將主庫的 DDL 和 DML 操作在 slave 實施。DML 和 DDL 的 IO 操作是隨即的，不是順 序的，成本高很多，還可能可 slave 上的其他查詢產生 lock 爭用，由于 Slave_SQL_Running 也是單線程的，所以一個 DDL 卡主了，需要 執行 10 分鐘，那么所有之后的 DDL 會等待這個 DDL 執行完才會繼續執行，這就導致了延時。有朋友會問：“主庫上那個相同的 DDL 也需要執行 10 分，為什 么 slave 會延時？”，答案是 master 可以并發，Slave_SQL_Running 線程卻不可以。
2. MySQL 數據庫主從同步延遲是怎么產生的。
答：當主庫的 TPS 并發較高時，產生的 DDL 數量超過 slave 一個 sql 線程所能承受的范圍，那么延時就產生了，當然還有就是可能與 slave 的大型 query 語句產生了鎖等待。
3. MySQL 數據庫主從同步延遲解決方案
答：最簡單的減少 slave 同步延時的方案就是在架構上做優化，盡量讓主庫的 DDL 快速執行。還有就是主庫是寫，對數據安全性較高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而 slave 則不需要這么高的數據安全，完全可以講 sync_binlog 設置為 0 或者關閉 binlog，innodb_flushlog 也 可以設置為 0 來提高 sql 的執行效率。另外就是使用比主庫更好的硬件設備作為 slave。
mysql-5.6.3 已經支持了多線程的主從復制。原理和丁奇的類似，丁奇的是以表做多線程，Oracle 使用的是以數據庫 (schema) 為單位做多線程，不同的庫可以使用不同的復制線程。
基于局域網的 master/slave 機制在通常情況下已經可以滿足 實時 備份的要求了。如果延遲比較大，就先確認以下幾個因素：
鴻蒙官方戰略合作共建——HarmonyOS 技術社區
網絡延遲
master 負載
slave 負載
一般的做法是，使用多臺 slave 來分攤讀請求，再從這些 slave 中取一臺專用的服務器，只作為備份用，不進行其他任何操作，就能相對 *** 限度地達到 實時 的要求了
slave_net_timeout 單位為秒 默認設置為 3600 秒 參數含義：當 slave 從主數據庫讀取 log 數據失敗后，等待多久重新建立連接并獲取數據 master-connect-retry 單位為秒 默認設置為 60 秒 參數含義：當重新建立主從連接時，如果連接建立失敗，間隔多久后重試。
通常配置以上 2 個參數可以減少網絡問題導致的主從數據同步延遲
判斷主從延時，通常有兩個方法：
1.Seconds_Behind_Master vs 2. mk-heartbeat，下面具體說下兩者在實現功能的差別。
可以通過監控 show slave statusG 命令輸出的 Seconds_Behind_Master 參數的值來判斷，是否有發生主從延時。
其值有這么幾種：
NULL - 表示 io_thread 或是 sql_thread 有任何一個發生故障，也就是該線程的 Running 狀態是 No, 而非 Yes。0 - 該值為零，是我們極為渴望看到的情況，表示主從復制良好，可以認為 lag 不存在。正值 - 表示主從已經出現延時，數字越大表示從庫落后主庫越多。負值 - 幾乎很少見，只是聽一些資深的 DBA 說見過，其實，這是一個 BUG 值，該參數是不支持負值的，也就是不應該出現。Seconds_Behind_Master 是通過比較 sql_thread 執行的 event 的 timestamp 和 io_thread 復制好的 event 的 timestamp(簡寫為 ts)進行比較，而得到的這么一個差值。我們都知道的 relay-log 和主庫的 bin-log 里面的內容完全一 樣，在記錄 sql 語句的同時會被記錄上當時的 ts，所以比較參考的值來自于 binlog，其實主從沒有必要與 NTP 進行同步，也就是說無需保證主從時鐘的 一致。你也會發現，其實比較真正是發生在 io_thread 與 sql_thread 之間，而 io_thread 才真正與主庫有關聯，于是，問題就出來了， 當主庫 I / O 負載很大或是網絡阻塞，io_thread 不能及時復制 binlog（沒有中斷，也在復制），而 sql_thread 一直都能跟上 io_thread 的腳本，這時 Seconds_Behind_Master 的值是 0，也就是我們認為的無延時，但是，實際上不是，你懂得。這也就是為什 么大家要批判用這個參數來監控數據庫是否發生延時不準的原因，但是這個值并不是總是不準，如果當 io_thread 與 master 網絡很好的情況下，那么 該值也是很有價值的。（就好比：媽 ndash; 兒子 ndash; 媳婦的關系，媽與兒子親人，媳婦和兒子也親人，不見得媳婦與媽就很親。開個玩笑:-）之前，提到 Seconds_Behind_Master 這個參數會有負值出現，我們已經知道該值是 io_thread 的最近跟新的 ts 與 sql_thread 執行到 的 ts 差值，前者始終是大于后者的，唯一的肯能就是某個 event 的 ts 發生了錯誤，比之前的小了，那么當這種情況發生時，負值出現就成為可能。
方法 2. mk-heartbeat，Maatkit*** 工具包中的一個工具，被認為可以準確判斷復制延時的方法。
mk-heartbeat 的實現也是借助 timestmp 的比較實現的，它首先需要保證主從服務器必須要保持一致，通過與相同的一個 NTP server 同步時鐘。它需要在主庫上創建一個 heartbeat 的表，里面至少有 id 與 ts 兩個字段，id 為 server_id，ts 就是當前的時間戳 now()，該結構也會被復制到從庫上，表建好以后，會在主庫上以后臺進程的模式去執行一行更新操作的命令，定期去向表中的插入數據，這個周期默認為 1 秒，同時從庫也會在后臺執行一個監控命令，與主庫保持一致的周期去比較，復制過來記錄的 ts 值與主庫上的同一條 ts 值，差值為 0 表示無延時，差值越大表示 延時的秒數越多。我們都知道復制是異步的 ts 不肯完全一致，所以該工具允許半秒的差距，在這之內的差異都可忽略認為無延時。這個工具就是通過實打實的復 制，巧妙的借用 timestamp 來檢查延時。
感謝各位的閱讀，以上就是“MySQL 主從數據庫同步延遲問題怎么解決”的內容了，經過本文的學習后，相信大家對 MySQL 主從數據庫同步延遲問題怎么解決這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
