MySQL案例-多源复制引起的内存泄漏-阿里云开发者社区

开发者社区> wangwenan> 正文

MySQL案例-多源复制引起的内存泄漏

简介: -------------------------------------------------------------------------------------------------正文-----------------------------------...
+关注继续查看
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
接前文: http://blog.itpub.net/29510932/viewspace-2129312/

场景 :
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)

关闭这个配置以后, 内存变化如上图的后半部分, 基本可以看到不再有明显的上升趋势;
需要注意的是, 并不一定就不再有内存泄漏的问题了, 希望官方早日修复~

PS: Null的测试继续拖, 写不动写不动写不动_(:з」∠)_

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MySQL案例-内存使用率无限增长
拖了好久了, 抽空补上  _(:з」∠)_ -------------------------------------------------------------------------------------------------正文-------------...
1315 0
MySQL 推出 90核 CPU 720GB 内存 独占物理机规格
信息摘要: RDS for MySQL 高可用版,本地盘实例支持最大 90核 CPU 720GB 内存独占物理机规格适用客户: 使用MySQL的客户,对性能要求很高的客户版本/规格功能: RDS for MySQL 高可用版,本地盘实例支持最大 90核 CPU 720GB 内存规格,有如下变动:① 上线支持最大 90核 CPU 720GB 内存规格,独占整个物理机;② 上线支持 64核 CPU 512GB 内存独享型规格,同时下线 60核 CPU 470GB 内存独占物理机规格;③ 上线支持 32核 CPU 256GB 内存独享型规格,同时下线 30核 CPU 220GB 内存独占物理机规格。
1154 0
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
7388 0
MySQL案例-多源复制引起的内存泄漏
-------------------------------------------------------------------------------------------------正文-----------------------------------...
2018 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
9100 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
10697 0
+关注
wangwenan
MySQL DBA
99
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《Nacos架构&原理》
立即下载
《看见新力量:二》电子书
立即下载
云上自动化运维(CloudOps)白皮书
立即下载