怎么理解MySQL中多源復(fù)制引起的內(nèi)存泄漏

怎么理解MySQL中多源復(fù)制引起的內(nèi)存泄漏，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

創(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ù)

場(chǎng)景 :
MySQL-5.7, 所有的小版本(<=17), percona-mysql-5.7所有版本;
開啟多源復(fù)制的只讀實(shí)例的內(nèi)存無限增長(zhǎng), 直到觸發(fā)系統(tǒng)的OOM Kill;

結(jié)論 :
mysql bug, 附上bug單鏈接: https://bugs.mysql.com/bug.php?id=85371

現(xiàn)象描述 :
內(nèi)存監(jiān)控如圖
怎么理解MySQL中多源復(fù)制引起的內(nèi)存泄漏

問題原因:
目前只能基于現(xiàn)象來分析;

開啟binlog_rows_query_log_events之后, 啟用多源復(fù)制的slave會(huì)出現(xiàn)內(nèi)存泄漏;
表現(xiàn)為內(nèi)存使用率不斷增長(zhǎng): 占用內(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í)。

當(dāng)前題目：怎么理解MySQL中多源復(fù)制引起的內(nèi)存泄漏
URL標(biāo)題：http://muchs.cn/article14/ipipge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、品牌網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站建設(shè)、App開發(fā)、網(wǎng)站導(dǎo)航、ChatGPT

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容