久久精品人人爽,华人av在线,亚洲性视频网站,欧美专区一二三

MySQL主從延遲現象及原理分析詳解

164次閱讀
沒有評論

共計 1839 個字符,預計需要花費 5 分鐘才能閱讀完成。

一、現象

凌晨對線上一張表添加索引,表數據量太大(1 億 + 數據,數據量 50G 以上),造成主從延遲幾個小時,各個依賴從庫的系統無法查詢數據,最終影響業務。

現在就梳理下主從延遲的原理。

二、原理

根據 MySQL 官方文檔 MySQL Replication Implementation Details 中的描述,MySQL 主從復制依賴于三個線程:master 一個線程(Binlog dump thread),slave 兩個線程(I/O thread 和 SQL thread)。主從復制流程如下圖:

MySQL 主從延遲現象及原理分析詳解

master 服務器和 slave 服務器連接時,創建 Binlog dump thread 以發送 bin log 數據:

一個 Binlog dump thread 對應一個 slave 服務器;
Binlog dump thread 從 bin log 獲取數據時會加鎖,獲取到數據后,立即釋放鎖。

當 slave 服務器收到 START_SLAVE 命令時,會創建 I /O thread 和 SQL thread:

I/O thread 以拉的方式,從 master 讀取事件,并存儲到 slave 服務器的 relay log 中;
SQL thread 從 relay log 中讀取事件并執行;
slave 可以按照自己的節奏讀取和更新數據,也可以隨意操作復制進程(啟動和停止)。

注: START_SLAVE 命令成功啟動線程后,如果后面 I /O thread 或 SQL thread 因為某些原因停止,則不會有任何的警告,業務方無法感知。可以通過查看 slave 的 error 日志,或者通過 SHOW SLAVE STATUS 查看 slave 上的線程狀態。

通過 SHOW PROCESSLIST 可查看線程狀態:

Binlog dump thread:

mysql SHOW PROCESSLIST\G
*************************** 1. row ***************************
 Id: 2
 User: root
 Host: localhost:32931
 db: NULL
Command: Binlog Dump
 Time: 94
 State: Has sent all binlog to slave; waiting for binlog to
 be updated
 Info: NULL

I/O thread 和 SQL thread:

mysql SHOW PROCESSLIST\G
*************************** 1. row ***************************
 Id: 10
 User: system user
 Host:
 db: NULL
Command: Connect
 Time: 11
 State: Waiting for master to send event
 Info: NULL
 *************************** 2. row ***************************
 Id: 11
 User: system user
 Host:
 db: NULL
Command: Connect
 Time: 11
 State: Has read all relay log; waiting for the slave I/O
 thread to update it
 Info: NULL

三、分析

根據上面的原理,由于 slave 是單線程 (I/O thread) 讀取數據,單線程 (SQL thread) 更新數據,而 master 是多線程寫入,那么只要 master 寫入的頻率大于 slave 讀取更新的頻率,就有可能出現主從延遲的情況,如:

master 寫入 tps 較高,大于 slave 更新速度;
slave 執行某些語句耗時較長,如持有鎖等;
master 執行某些 DDL 語句時,執行的時間較長,在 slave 也執行相同的時間;

此處創建了索引,咨詢 DBA,產生的 bin log 文件有 100 多 G,數據量太大,導致從庫 I /O thread 一直讀取 DDL 操作產生的 bin log 事件,而影響到正常的業務 DML 事件的更新,從而表現為主從同步延遲。

四、解決方案

從主從延遲的原因來看,解決方案可以從以下幾個方向入手:

業務選型,對于無法忍受從庫延遲的架構,可選擇分布式架構等,避開從庫延遲問題
執行時間,對大表進行線上 DDL 操作盡量選擇凌晨等業務量較小的時候
硬件配置,升級從庫硬件配置,如 SSD
減少請求,增加緩存層,減少讀請求落庫

總結

以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對丸趣 TV 的支持。如果你想了解更多相關內容請查看下面相關鏈接

向 AI 問一下細節

丸趣 TV 網 – 提供最優質的資源集合!

正文完
 
丸趣
版權聲明:本站原創文章,由 丸趣 2023-12-18發表,共計1839字。
轉載說明:除特殊說明外本站除技術相關以外文章皆由網絡搜集發布,轉載請注明出處。
評論(沒有評論)
主站蜘蛛池模板: 卢氏县| 新蔡县| 新晃| 广灵县| 绥化市| 湖州市| 水富县| 花垣县| 宁阳县| 临沂市| 柳州市| 河北区| 黄浦区| 米易县| 宁晋县| 阿拉善盟| 沙坪坝区| 丰顺县| 图们市| 清远市| 本溪| 荥阳市| 义马市| 鄂伦春自治旗| 大城县| 永济市| 平果县| 雅江县| 阿荣旗| 福清市| 株洲县| 东海县| 芜湖县| 晋中市| 灵璧县| 措美县| 游戏| 内乡县| 八宿县| 沅陵县| 无极县|