怎么理解MySQL中多源復制引起的內存泄漏

怎么理解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

點擊(此處)折疊或打開

1. *************************** 2. row ***************************
   

2.                    THREAD_ID: 18189
   

3.                   EVENT_NAME: memory/sql/Log_event
   

4.                  COUNT_ALLOC: 521692
   

5.                   COUNT_FREE: 0
   

6.    SUM_NUMBER_OF_BYTES_ALLOC: 117988604
   

7.     SUM_NUMBER_OF_BYTES_FREE: 0
   

8. ...
   

9.     LOW_NUMBER_OF_BYTES_USED: 25286276
   

10. CURRENT_NUMBER_OF_BYTES_USED: 117988604
    

11.    HIGH_NUMBER_OF_BYTES_USED: 117988604
    

12. *************************** 3. row ***************************
    

13.                    THREAD_ID: 18183
    

14.                   EVENT_NAME: memory/sql/Log_event
    

15.                  COUNT_ALLOC: 521426
    

16.                   COUNT_FREE: 0
    

17.    SUM_NUMBER_OF_BYTES_ALLOC: 117732632
    

18.     SUM_NUMBER_OF_BYTES_FREE: 0
    

19. ...
    

20.     LOW_NUMBER_OF_BYTES_USED: 25154914
    

21. CURRENT_NUMBER_OF_BYTES_USED: 117732632
    

22.    HIGH_NUMBER_OF_BYTES_USED: 117732632

兩小時以后:

點擊(此處)折疊或打開

1. *************************** 1. row ***************************
   

2.                    THREAD_ID: 18189
   

3.                   EVENT_NAME: memory/sql/Log_event
   

4.                  COUNT_ALLOC: 2297022
   

5.                   COUNT_FREE: 0
   

6.    SUM_NUMBER_OF_BYTES_ALLOC: 525744164
   

7.     SUM_NUMBER_OF_BYTES_FREE: 0
   

8. ...
   

9.     LOW_NUMBER_OF_BYTES_USED: 25286276
   

10. CURRENT_NUMBER_OF_BYTES_USED: 525744164
    

11.    HIGH_NUMBER_OF_BYTES_USED: 525744164
    

12. *************************** 2. row ***************************
    

13.                    THREAD_ID: 18183
    

14.                   EVENT_NAME: memory/sql/Log_event
    

15.                  COUNT_ALLOC: 2296412
    

16.                   COUNT_FREE: 0
    

17.    SUM_NUMBER_OF_BYTES_ALLOC: 524600639
    

18.     SUM_NUMBER_OF_BYTES_FREE: 0
    

19. ...
    

20.     LOW_NUMBER_OF_BYTES_USED: 25154914
    

21. CURRENT_NUMBER_OF_BYTES_USED: 524600639
    

22.    HIGH_NUMBER_OF_BYTES_USED: 524600639

event對應的線程:

點擊(此處)折疊或打開

1. *************************** 1. row ***************************
   

2.         thd_id: 18183
   

3.        conn_id: 18158
   

4.           user: sql/slave_sql
   

5.        command: Sleep
   

6.          state: Slave has read all relay log; waiting for more updates
   

7. current_memory: 532.28 MiB
   

8. *************************** 2. row ***************************
   

9.         thd_id: 18189
   

10.        conn_id: 18164
    

11.           user: sql/slave_sql
    

12.        command: Sleep
    

13.          state: Slave has read all relay log; waiting for more updates
    

14. current_memory: 533.50 MiB
    

15. 2 rows in set (0.10 sec)

解決方案 :
關閉binlog_rows_query_log_events(默認就是關閉的),
實際上這個參數主要是控制binlog中是否記錄原始SQL語句的, 主要是Debug用;
而平時用-vv來解析binlog以后, 本身也會注明row模式中的SQL語句, 可讀性也還可以接受;

這個bug目前是S2(Serious)

關閉這個配置以后, 內存變化如上圖的后半部分, 基本可以看到不再有明顯的上升趨勢;
需要注意的是, 并不一定就不再有內存泄漏的問題了。

關于怎么理解MySQL中多源復制引起的內存泄漏問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。