共計 2472 個字符，預計需要花費 7 分鐘才能閱讀完成。
怎么理解 MySQL 中多源復制引起的內存泄漏，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
場景 :
MySQL-5.7, 所有的小版本 (=17), percona-mysql-5.7 所有版本;
開啟多源復制的只讀實例的內存無限增長, 直到觸發系統的 OOM Kill;
結論 :
mysql bug, 附上 bug 單鏈接: https://bugs.mysql.com/bug.php?id=85371
現象描述 :
內存監控如圖
問題原因:
目前只能基于現象來分析;
開啟 binlog_rows_query_log_events 之后, 啟用多源復制的 slave 會出現內存泄漏;
表現為內存使用率不斷增長: 占用內存的為 slave_sql 線程, 數據庫事件為 memory/sql/Log_event;
相關數據 (來源于截圖中的實例):
重啟只讀 slave 之后, 相關事件的內存使用:
申請了內存, 但是沒有釋放過: COUNT_FREE, SUM_NUMBER_OF_BYTES_FREE 為 0
點擊 (此處) 折疊或打開
*************************** 2. row ***************************
THREAD_ID: 18189
EVENT_NAME: memory/sql/Log_event
COUNT_ALLOC: 521692
COUNT_FREE: 0
SUM_NUMBER_OF_BYTES_ALLOC: 117988604
SUM_NUMBER_OF_BYTES_FREE: 0
…
LOW_NUMBER_OF_BYTES_USED: 25286276
CURRENT_NUMBER_OF_BYTES_USED: 117988604
HIGH_NUMBER_OF_BYTES_USED: 117988604
*************************** 3. row ***************************
THREAD_ID: 18183
EVENT_NAME: memory/sql/Log_event
COUNT_ALLOC: 521426
COUNT_FREE: 0
SUM_NUMBER_OF_BYTES_ALLOC: 117732632
SUM_NUMBER_OF_BYTES_FREE: 0
…
LOW_NUMBER_OF_BYTES_USED: 25154914
CURRENT_NUMBER_OF_BYTES_USED: 117732632
HIGH_NUMBER_OF_BYTES_USED: 117732632
兩小時以后:
點擊 (此處) 折疊或打開
*************************** 1. row ***************************
THREAD_ID: 18189
EVENT_NAME: memory/sql/Log_event
COUNT_ALLOC: 2297022
COUNT_FREE: 0
SUM_NUMBER_OF_BYTES_ALLOC: 525744164
SUM_NUMBER_OF_BYTES_FREE: 0
…
LOW_NUMBER_OF_BYTES_USED: 25286276
CURRENT_NUMBER_OF_BYTES_USED: 525744164
HIGH_NUMBER_OF_BYTES_USED: 525744164
*************************** 2. row ***************************
THREAD_ID: 18183
EVENT_NAME: memory/sql/Log_event
COUNT_ALLOC: 2296412
COUNT_FREE: 0
SUM_NUMBER_OF_BYTES_ALLOC: 524600639
SUM_NUMBER_OF_BYTES_FREE: 0
…
LOW_NUMBER_OF_BYTES_USED: 25154914
CURRENT_NUMBER_OF_BYTES_USED: 524600639
HIGH_NUMBER_OF_BYTES_USED: 524600639
event 對應的線程:
點擊 (此處) 折疊或打開
*************************** 1. row ***************************
thd_id: 18183
conn_id: 18158
user: sql/slave_sql
command: Sleep
state: Slave has read all relay log; waiting for more updates
current_memory: 532.28 MiB
*************************** 2. row ***************************
thd_id: 18189
conn_id: 18164
user: sql/slave_sql
command: Sleep
state: Slave has read all relay log; waiting for more updates
current_memory: 533.50 MiB
2 rows in set (0.10 sec)
解決方案 :
關閉 binlog_rows_query_log_events(默認就是關閉的),
實際上這個參數主要是控制 binlog 中是否記錄原始 SQL 語句的, 主要是 Debug 用;
而平時用 -vv 來解析 binlog 以后, 本身也會注明 row 模式中的 SQL 語句, 可讀性也還可以接受;
這個 bug 目前是 S2(Serious)
關閉這個配置以后, 內存變化如上圖的后半部分, 基本可以看到不再有明顯的上升趨勢;
需要注意的是, 并不一定就不再有內存泄漏的問題了。
關于怎么理解 MySQL 中多源復制引起的內存泄漏問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。
