溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
怎么理解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中多源復制引起的內存泄漏問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
