怎么理解MySQL中多源復(fù)制引起的內(nèi)存泄漏，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。
創(chuàng)新互聯(lián)公司專注于朝陽企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,購物商城網(wǎng)站建設(shè)。朝陽網(wǎng)站建設(shè)公司,為朝陽等地區(qū)提供建站服務(wù)。全流程專業(yè)公司，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)
場景 :
MySQL-5.7, 所有的小版本(<=17), percona-mysql-5.7所有版本;
開啟多源復(fù)制的只讀實(shí)例的內(nèi)存無限增長, 直到觸發(fā)系統(tǒng)的OOM Kill;
結(jié)論 :
mysql bug, 附上bug單鏈接: https://bugs.mysql.com/bug.php?id=85371
現(xiàn)象描述 :
內(nèi)存監(jiān)控如圖
問題原因:
目前只能基于現(xiàn)象來分析;
開啟binlog_rows_query_log_events之后, 啟用多源復(fù)制的slave會(huì)出現(xiàn)內(nèi)存泄漏;
表現(xiàn)為內(nèi)存使用率不斷增長: 占用內(nèi)存的為slave_sql線程, 數(shù)據(jù)庫事件為memory/sql/Log_event;
相關(guān)數(shù)據(jù)(來源于截圖中的實(shí)例):
重啟只讀slave之后, 相關(guān)事件的內(nèi)存使用:
申請(qǐng)了內(nèi)存,但是沒有釋放過: COUNT_FREE, SUM_NUMBER_OF_BYTES_FREE為0
點(diǎn)擊(此處)折疊或打開
*************************** 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
兩小時(shí)以后:
點(diǎn)擊(此處)折疊或打開
*************************** 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對(duì)應(yīng)的線程:
點(diǎn)擊(此處)折疊或打開
*************************** 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)
解決方案 :
關(guān)閉binlog_rows_query_log_events(默認(rèn)就是關(guān)閉的),
實(shí)際上這個(gè)參數(shù)主要是控制binlog中是否記錄原始SQL語句的, 主要是Debug用;
而平時(shí)用-vv來解析binlog以后, 本身也會(huì)注明row模式中的SQL語句, 可讀性也還可以接受;
這個(gè)bug目前是S2(Serious)
關(guān)閉這個(gè)配置以后, 內(nèi)存變化如上圖的后半部分, 基本可以看到不再有明顯的上升趨勢(shì);
需要注意的是, 并不一定就不再有內(nèi)存泄漏的問題了。
關(guān)于怎么理解MySQL中多源復(fù)制引起的內(nèi)存泄漏問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
重慶分公司
重慶分公司
