怎么理解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中多源复制引起的内存泄漏问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。

分享文章：怎么理解MySQL中多源复制引起的内存泄漏
URL链接：http://kswjz.com/article/ipipge.html