阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

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

188次阅读
没有评论

共计 2578 个字符,预计需要花费 7 分钟才能阅读完成。

场景 :
MySQL-5.7, 所有的小版本(<=17), percona-mysql-5.7 所有版本; 开启多源复制的只读实例的内存无限增长, 直到触发系统的 OOM Kill;

接前文:http://www.linuxidc.com/Linux/2016-12/137852.htm

结论 :
mysql bug, 附上 bug 单链接: https://bugs.mysql.com/bug.php?id=85371

现象描述 :
内存监控如图

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

问题原因:
目前只能基于现象来分析;

开启 binlog_rows_query_log_events 之后, 启用多源复制的 slave 会出现内存泄漏;
表现为内存使用率不断增长: 占用内存的为 slave_sql 线程, 数据库事件为 memory/sql/Log_event;

相关数据 (来源于截图中的实例):
重启只读 slave 之后, 相关事件的内存使用:
申请了内存, 但是没有释放过: COUNT_FREE, SUM_NUMBER_OF_BYTES_FREE 为 0

*************************** 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

两小时以后:

*************************** 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 对应的线程:

*************************** 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)

解决方案 :
关闭 binlog_rows_query_log_events(默认就是关闭的),
实际上这个参数主要是控制 binlog 中是否记录原始 SQL 语句的, 主要是 Debug 用;
而平时用 -vv 来解析 binlog 以后, 本身也会注明 row 模式中的 SQL 语句, 可读性也还可以接受;

这个 bug 目前是 S2(Serious)

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

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

本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-04/142925.htm

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-22发表,共计2578字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中