Mysql 5.7.17 从库内存一直增长至omm

最新推荐文章于 2024-09-08 22:35:28 发布
置顶 最新推荐文章于 2024-09-08 22:35:28 发布
阅读量2.9k 收藏 2
点赞数 2
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_42942173/article/details/103739003
版权

Mysql 5.7.17 从库内存一直增长至omm

mysql 5.7bug部分版本主从gtid模式从库设置super_read_only=on内存一直增长至omm现象分析、复现、及升级后验证

bug #84332说明：
Bug #84332，在5.7.17 5.7.16版本主从使用gtid模式，并且从库打开了super_read_only=on从库内存一直增长时间长了就会产生omm.
set super_read_only = 1 on slaves(with grid_mode=1), compression of mysql.gtid_executed has been prevented, and finally cause OOM.

一、现象：

系统背景介绍：
1、系统A
mysql 5.7.17数据库，架构是主从架构 ，虚拟机2台，内存16G.
A主从: A主库，A从库

2、系统B
mysql 5.7.17数据库，架构是主从架构 ，虚拟机2台，内存16G.
B主从: B主库，B从库

3、系统C
mysql 5.7.17数据库，架构是主从架构 ，物理机3台，其中1，2号物理机使用系统HA共享存储做主库，3号物理机做从库，内存都是128G.
C主从: C主库，C从库

问题描述：

1、系统A
主从A主从关系一直正常，发现A从库出现了内存一直增长问题，直到使用了swap空间，其中第一次数据库停止时候一直hang住十几分钟，都没有反应，mysql日志也没相关输出，最后重启了系统内存释放。A从库内存会不断增长直到内存快使用完，为避免彻底的oom会在内存耗尽前重启从库系统，此场景周期性的出现重启了三次。

主从A
重启前收集：
Free -m
total used free shared buff/cache available
Mem: 15886 15367 168 20 350 156
Swap: 8191 1769 6422

主从A
重启系统和数据库后内存使用
free -m
total used free shared buff/cache available
Mem: 15886 2616 12101 9 1168 12960
Swap: 8191 0 8191

2、系统B
另一套主从B的mysql版本和内存及mysql缓冲池配置和主从A配置一样，但是没有出现从库内存一直增长问题。

3、系统C
mysql 5.7.17数据库，架构是主从架构 ，物理机3台，其中1，2号物理机使用系统HA共享存储做主库，3号物理机做从库，内存都是128G。系统C出现从库内存不断增长，从库128G内存剩余free只有12G，为防止omm重启了从库数据库和系统。

二、分析：
1、对比主从A和主从B、主从C的从库下面配置

所有从库都打开了read_only=on，差异配置如下
从库A log_slave_updates=1,super_read_only =on
从库B log_slave_updates=0,super_read_only =off
从库C log_slave_updates=0,super_read_only =on

2、怀疑触发了bug
主从A的从库重启后，从库还是反复性一直增长，同时主从C的从库内存也出现一直增长。怀疑还是主从复制有关，而且在某些设置条件下，某些线程一直申请内存没有释放，经过查询相关资料mysql版本MySQL5.7的版本<=5.7.17，而且从库在设置super_read_only=on会触发bug #84332,主从A mysql版本是5.7.17，而且从库设置了super_read_only=on 满足其bug触发条件。

相关原因：
MySQL 5.6使用gtid必须打开log_slave_updates，存储会有一定额外的开销。MySQL 5.7引入了表gtid_executed，MySQL 5.7引入了表gtid_executed，解决了开启GTID必须要开启参数log_slave_updates问题。

若启用GTID并且不启用线程log_slave_updates，则表gtid_executed会不断增大，每次事务提交会将当前GTID写入到该表。为避免此表不断增大，MySQL引入GTID合并线程thread/sql/compress_gtid_table，定期来合并这张表。参数gtid_executed_compression_period 用来控制GTID合并的频率。
然而，在MySQL 5.7.17及之前的版本中，从库设置super_read_only = on时，MySQL会认为当前是只读的，应该阻止所有DML操作，因此GTID合并线程也会失败，而失败的GTID合并线程会不断地重试。
此外，由于合并失败，表gtid_executed的记录数会不断增大，合并所需占用的内存不断增加，从而导致OOM。

相关背景机制说明：

mysql.gtid_exected表
GTID存储在mysql库中gtid_executed表中。该表中的一行针对它代表的每个GTID或一组GTID包含原始服务器的UUID，以及该组的起始和结束事务ID；对于仅引用单个GTID的行，最后两个值相同。

当从库上禁用二进制日志记录时，该表使从库可以保存GTID，而当二进制日志丢失时，mysql.gtid_executed使保留GTID历史记录。

GTID仅在gtid_mode模式为ON或ON_PERMISSIVE时存储在mysql.gtid_executed表中。GTID的存储点取决于是否启用了二进制日志记录：

如果禁用了二进制日志记录，或如果log_slave_updates被禁用，则从库会把每个事务的GTID与该事务一起存储在表中。此外，该表会以用户定义设置的压缩参数压缩。这种情况仅适用于禁用了二进制日志记录或不更新日志记录的从库。它不适用于主库，因为必须在主库上启用二进制日志记录才能进行复制。

如果启用了二进制日志记录，则每当轮换二进制日志或关闭数据库时，从库都会将写入前一个二进制日志的所有事务的GTID写入gtid_executed表中，这种情况适用于启用了二进制日志记录的主库或从库。

如果从库意外停止，则当前二进制日志中的GTID集不会保存在 mysql.gtid_executed表中，在这种情况下，这些GTID将gtid_executed在恢复期间添加到表和系统变量中的GTID集合中。

启用二进制日志记录后，gtid_executed表不保证为所有已执行的事务保存完整的GTID记录，该信息由gtid_executed 系统变量的全局值保证。

gtid_executed表由RESET MASTER重置。

mysql.gtid_executed表压缩

随着时间的增长， mysql.gtid_executed表中可能会出现很多行，这些行引用源自同一服务器的各个GTID，并且其事务ID组成一个序列，类似于此处所示：

mysql> SELECT * FROM mysql.gtid_executed;

  • -------------------------------------- + ---------- ------ + -------------- +
    | source_uuid | interval_start | interval_end |
    | -------------------------------------- + ---------- ------ + -------------- |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 37 |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 38 | 38 |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 39 | 39 |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 40 | 40 |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 41 | 41 |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 42 | 42 |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 43 | 43 |
    …
    如果定期压缩此表，可以用跨事务标识符整个间隔的单行替换每个这样的行集来节省大量空间，如下所示：

  • -------------------------------------- + ---------- ------ + -------------- +
    | source_uuid | interval_start | interval_end |
    | -------------------------------------- + ---------- ------ + -------------- |
    | 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37 | 43 |
    …
    启用GTID后，从库会定期在mysql.gtid_executed表上执行这种类型压缩。通过设置gtid_executed_compression_period系统变量，此变量默认值为1000，这意味着，表压缩在每1000个事务后执行。设置gtid_executed_compression_period为0则不执行压缩。如果这样做，应该准备增加gtid_executed表可能需要的大量磁盘空间量。

注意
当启用二进制日志，gtid_executed_compression_period 是不起作用的，mysql.gtid_executed表在每个二进制日志发生轮换时候进行压缩。

mysql.gtid_executed表的由名为的专用线程thread/sql/compress_gtid_table压缩。该线程未在的输出中列出SHOW PROCESSLIST，但可以在threads表中查询 ，如下所示：

mysql> SELECT * FROM performance_schema.threads WHERE NAME LIKE ‘%gtid%’\G
*************************** 1. row ***************************
THREAD_ID: 26
NAME: thread/sql/compress_gtid_table
TYPE: FOREGROUND
PROCESSLIST_ID: 1
PROCESSLIST_USER: NULL
PROCESSLIST_HOST: NULL
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Daemon
PROCESSLIST_TIME: 1509
PROCESSLIST_STATE: Suspending
PROCESSLIST_INFO: NULL
PARENT_THREAD_ID: 1
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: NULL
THREAD_OS_ID: 18677
thread/sql/compress_gtid_table通常休眠，直到gtid_executed_compression_period条件已经被触发，那么唤醒到的执行压缩mysql.gtid_executed如前所述表。然后休眠，直到发生gtid_executed_compression_period参数事务值为止，然后唤醒以再次执行压缩，并无限期重复此循环。
禁用二进制日志记录时将此值设置为0意味着线程始终处于休眠状态，并且永远不会唤醒。

三、复现：

环境准备：
测试环境安装mysql 5.7.17,配置同生产一直是gtid方式主从复制。
xx.x.xxx.116 从库
xx.x.xxx.117 主库
主库创建表：
create database appdb;
create table emp(name varchar(10), hiredata date,sal decimal(10,2),deptno int(2));
主库通过mysql自带压测工具进行测试，每次插入100条数据
mysqlslap -uroot -pxxt@hjgl --concurrency=100 --iterations=1 --create-schema=‘appdb’ --query=“insert into appdb.emp values(‘suse’,‘2019-03-19’,‘300’,2)” --engine=innodb --number-of-queries=10

场景一、从库设置log-slave-updates=1，super_read_only=off

当从库打开log-slave-updates=1 ，而且super_read_only=off
mysql.gtid_executed;始终是两条记录
从库查询表
主库执行第一批次压测命令，从库查看gtid_executed表
mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| 38d440ec-48a2-11e9-b94a-005056991dcd | 1 | 27604 |记录主库执行的gitd信息
| 6102de5a-48a0-11e9-ab8f-00505699b577 | 1 | 9 |
±-------------------------------------±---------------±-------------+
2 rows in set (0.00 sec)
主库第二批次执行压测命令：
mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| 38d440ec-48a2-11e9-b94a-005056991dcd | 1 | 27703 |记录主库执行的gitd信息
| 6102de5a-48a0-11e9-ab8f-00505699b577 | 1 | 9 |

结论：一切正常。

场景二、 从库设置log_slave_updates=1，super_read_only =on

当从库打开log-slave-updates=1 ，而且super_read_only=on
设置binlog日志最大值为1000字节。好观察日志轮换时候gtid信息记录情况。主库执行第一次压测命令：查看表mysql.gtid_executed数据不是两条不变了，增加了不少。
mysql> select count() from mysql.gtid_executed;
±---------+
| count() |
±---------+
| 107 |
±---------+
1 row in set (0.00 sec)

无论gtid id记录数怎么增加，之前的压缩值一直没有27703变化
mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| 38d440ec-48a2-11e9-b94a-005056991dcd | 1 | 27703 | -此压缩值不变
………………………………………………………………………………………………………………………………

| 38d440ec-48a2-11e9-b94a-005056991dcd | 27704 | 27720 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 27721 | 27748 |
…………………………………………………………………………………………………………………………………
| 38d440ec-48a2-11e9-b94a-005056991dcd | 30969 | 31000 |
| 6102de5a-48a0-11e9-ab8f-00505699b577 | 1 | 9 |
±-------------------------------------±---------------±-------------+
107 rows in set (0.00 sec)
主库执行第二次压测命令：查询mysql.gtid_executed的条数又在增加，显示从库每刷新一个日志，就增加一条。
mysql> select count() from mysql.gtid_executed;
±---------+
| count() |
±---------+
| 534 |
±---------+
1 row in set (0.00 sec)

mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| 38d440ec-48a2-11e9-b94a-005056991dcd | 1 | 27703 |-此压缩值不变
| 38d440ec-48a2-11e9-b94a-005056991dcd | 27704 | 27720 |
………………………………………………………………………………………………
| 38d440ec-48a2-11e9-b94a-005056991dcd | 44339 | 44366 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 44367 | 44404 |
| 6102de5a-48a0-11e9-ab8f-00505699b577 | 1 | 9 |
±-------------------------------------±---------------±-------------+
534 rows in set (0.00 sec)
从库查看innodb引擎状态，发现了压缩mysql.gtid_executed失败回滚的信息。
mysql> show ENGINE innodb STATUS \G;
—TRANSACTION 852413, ACTIVE 0 sec rollback
mysql tables in use 1, locked 1
ROLLING BACK 5 lock struct(s), heap size 1136, 534 row lock(s), undo log entries 29
MySQL thread id 29, OS thread handle 140702339127040, query id 0 Compressing gtid_executed table
显示压缩表gtid_executed table失败，回滚中。

此时停止从库会一致hang住，同生产停从库的场景一样。

结论：
当日志发生轮换时候会把轮换当前的日志gtid信息写入到mysql.gtid_executed;也就是说每个一日志记录自己事务开始和结束gtid信息，发生日志轮换时触发压缩，时间长了因压缩失败导致从库内存oom;

场景三、 从库设置log_slave_updates=0，super_read_only =on
接上一场景，强制kill从库进程，重启从库，reset master，清除之前的gtid信息。
mysql> set global gtid_executed_compression_period=1;
mysql> set global super_read_only=on;
mysql> show master logs;
±-----------------±----------+
| Log_name | File_size |
±-----------------±----------+
| mysql-bin.000001 | 154 |
±-----------------±----------+
1 row in set (0.00 sec)

mysql>
mysql> select * from mysql.gtid_executed;
Empty set (0.00 sec)

主库执行压测命令，只写入100条数据
从库看
mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| 38d440ec-48a2-11e9-b94a-005056991dcd | 1 | 1 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 2 | 2 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 3 | 3 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 4 | 4 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 5 | 5 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 6 | 6 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 7 | 7 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 8 | 8 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 9 | 9 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 10 | 10 |
| 38d440ec-48a2-11e9-b94a-005056991dcd | 11 | 11 |
………………………………………………………………………………………………
| 38d440ec-48a2-11e9-b94a-005056991dcd | 100 | 100 |
±-------------------------------------±---------------±-------------+
100 rows in set (0.00 sec)
显示每个事务写一条gtid信息。

因为mysql.gtid_executed不能压缩成功，也会导致omm。

结论：
当从库打开log-slave-updates=0 ，而且super_read_only=on每个事务的gtid都会写入到mysql.gtid_executed导致从库使用内存增长较快导致oom。
比如主从C 的从库就是上面设置，导致出现从库内存不断增长，从库128G内存剩余free只有12G。

四、升级后验证：
升级到5.7.22 验证能正常压缩：

环境准备
安装mysql 5.7.22 版本测试，搭建gtid复制方式的主从
ip xx.x.xxx.8 主
ip xx.x.xxx.9 从

场景一，从库设置log_slave_updates = 0,global super_read_only = on;看是否能正常压缩

设置从库gtid_executed_compression_period =1000

主库建表
create table emp(name varchar(10), hiredata date,sal decimal(10,2),deptno int(2));
主库每次500条数据压测
[citicsql@mha1 etc]$ mysqlslap -uroot -pxxt@hjgl --concurrency=500 --iterations=1 --create-schema=‘appdb’ --query=“insert into appdb.emp values(‘suse’,‘2019-03-19’,‘300’,2)” --engine=innodb --number-of-queries=10

从库信息查看
主从建立后
mysql> SELECT COUNT(1) FROM mysql.gtid_executed;
±---------+
| COUNT(1) |
±---------+
| 0 |
±---------+
1 row in set (0.00 sec)

主库创建表后
从库查看
mysql> SELECT COUNT(1) FROM mysql.gtid_executed;
±---------+
| COUNT(1) |
±---------+
| 1 |
±---------+
1 row in set (0.00 sec)

mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1 | 1 |
±-------------------------------------±---------------±-------------+

当主库插入500条数后

从库查看
mysql> select count() from appdb.emp;
±---------+
| count() |
±---------+
| 500 |
±---------+
1 row in set (0.00 sec)
mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1 | 1 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 2 | 2 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 3 | 3 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4 | 4 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 5 | 5 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 6 | 6 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 7 | 7 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 8 | 8 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 9 | 9 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 10 | 10 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 11 | 11 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 12 | 12 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 13 | 13 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 14 | 14 |
…
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 500 | 500 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 501 | 501 |
±-------------------------------------±---------------±-------------+
501 rows in set (0.00 sec)

当主库再插入1500条数后
mysql> select count() from appdb.emp;
±---------+
| count() |
±---------+
| 2000 |
±---------+
mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1 | 1001 | 显示压缩成功
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1002 | 1002 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1003 | 1003 |
…
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 2000 | 2000 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 2001 | 2001 |
±-------------------------------------±---------------±-------------+
1001 rows in set (0.00 sec)

当从库查看表appdb.emp 4500时候
mysql> select count() from appdb.emp;
±---------+
| count() |
±---------+
| 4500 |
±---------+
1 row in set (0.01 sec)

mysql> select count() from mysql.gtid_executed;
±---------+
| count() |
±---------+
| 482 |
±---------+
1 row in set (0.00 sec)
mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1 | 4020 |再次压缩
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4021 | 4021 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4022 | 4022 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4023 | 4023 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4024 | 4024 |
…
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4498 | 4498 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4499 | 4499 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4500 | 4500 |
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 4501 | 4501 |
±-------------------------------------±---------------±-------------+
482 rows in set (0.00 sec)

**结论：**5.7.22版本在从库设置log_slave_updates = 0， global super_read_only = on gtid事务可以正常压缩。

场景二，从库设置log_slave_updates = 1,global super_read_only = on;看是否能正常压缩

设置从库gtid_executed_compression_period =1000

mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end |
±-------------------------------------±---------------±-------------+
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1 | 489 |
±-------------------------------------±---------------±-------------+
1 row in set (0.00 sec)

mysql> select count() from appdb.emp;
±---------+
| count() |
±---------+
| 500 |
±---------+
1 row in set (0.00 sec)

mysql> show master logs;
±-----------------±----------+
| Log_name | File_size |
±-----------------±----------+
| mysql-bin.000001 | 7204 |
| mysql-bin.000002 | 4577 |
| mysql-bin.000003 | 7558 |
| mysql-bin.000004 | 4306 |
| mysql-bin.000005 | 7829 |
| mysql-bin.000006 | 6474 |
| mysql-bin.000007 | 5390 |
| mysql-bin.000008 | 7829 |
| mysql-bin.000009 | 7829 |
| mysql-bin.000010 | 7829 |
| mysql-bin.000011 | 7829 |
| mysql-bin.000012 | 7829 |
| mysql-bin.000013 | 9184 |
| mysql-bin.000014 | 10268 |
| mysql-bin.000015 | 7829 |
| mysql-bin.000016 | 7829 |
| mysql-bin.000017 | 6745 |
| mysql-bin.000018 | 5119 |
| mysql-bin.000019 | 7558 |
| mysql-bin.000020 | 3446 |
±-----------------±----------+
20 rows in set (0.00 sec)

mysql>

mysql> select count() from appdb.emp;
±---------+
| count() |
±---------+
| 4500 |
±---------+
1 row in set (0.01 sec)

mysql> select * from mysql.gtid_executed;
±-------------------------------------±---------------±-------------+
| source_uuid | interval_start | interval_end | 已经压缩
±-------------------------------------±---------------±-------------+
| a0b3dfa5-4d64-11e9-8eb9-005056999e31 | 1 | 4501 |
±-------------------------------------±---------------±-------------+
1 row in set (0.00 sec)

结论：
5.7.22版本在从库设置log_slave_updates = 1， global super_read_only = on gtid事务可以正常压缩。

总结：

Bug #84332，在5.7.17 5.7.16版本主从使用gtid模式，并且从库打开了super_read_only=on;从库内存一直增长时间长了就会产生omm.

一、
从库打开log_slave_updates=1， super_read_only =on
当日志发生轮换时候会把轮换当前的日志gtid信息写入到mysql.gtid_executed;也就是说每个一日志记录自己事务开始和结束gtid信息，发生日志轮换时也触发压缩，时间长了因压缩失败导致从库内存oom;

二、
从库打开log-slave-updates=0 ，而且super_read_only=ON每个事务的gtid都会写入到mysql.gtid_executed，
当达到默认gtid_executed_compression_period =1000条件，也就是每执1000个事务后时候触发压缩，导致从库可能较快oom。

三、
升级至5.7.22后gtid压缩正常，从库打开super_read_only=on也能正常压缩gitd信息了。

四、
解决办法，遇到此问题升级mysql版本，可至升级mysql 5.7.22以上版本。

压测遇到OOM记录
xiaoxie777的博客
06-15 331
1.内存溢出问题排查 2.性能测试
mysql5.7 OOM内存溢出问题排查
cdrcsy的专栏
09-20 5649
MySQL内存泄露排查。 单位：  B是Byte的缩写，B就是Byte，也就是字节（Byte）；b是bit的缩写，b就是bit，也就是比特位（bit）。     8bit（比特位）=1Byte（字节）；     1024Byte（字节）=1KB(千字节)；     1024KB（千字节）=1MB（兆字节）;     1024MB=1GB;     1024GB=1TB; 如何知道mysqld...
mysql5.7内存占用持续过高
风的专栏
04-29 1万+
table_open_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。 通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_open_cache的值。 如果你发现open_tables等于table_open_cache，并且opened_tabl...
Mysql5.7内存持续增高的解决方案及说明
热门推荐
kouryoushine的博客
04-17 1万+
背景 阿里云服务器搭建了主从服务器，近期发现mysql5.7占用了服务器71%的内存。并且每天仍然有不断扩充的趋势。为了避免内存爆炸，调查了一下内存增加的原因和解决方法。调研的过程学习了很多资料，这里只说结论供大家参考。 服务器：4cpu 8GB内存 解决方案 降低innodb_buffer_pool_size，并修改配置文件 ## 修改前的值根据内存的80%来设定 mysql> SELEC...
OMM
root先生的博客
07-19 2146
OMM主要三类： permgen OOM ,heap OOM, stack overflow  permgen OOM: 这个主要是由于加载的类太多，或者反射的类太多，还有调用 String.intend（jdk7之前）也会造成这个问题。所以出现了这个问题，就检查这三个方面； heap OOM：主要是因为一些无用对象没有及时释放造成的，检查代码加上 heap dump 去分析. stack
优化 - 重构一次Mysql导致服务器的OOM
stark张宇
01-13 710
优化了一次前后端处理不当导致的CPU的一次爆机行为，当然，这和服务器的配置低也有着密不可分的关系，简单的逻辑学告诉我们，要找到真正的问题，进行解决，CPU爆机的关键点在于前后端两个方面，下面针对具体的问题，进行分析和解决。
Java内存泄漏OMM
weixin_44137260的博客
08-01 1592
JVM 发生 OOM 的 8 种原因、及解决办法 高手总结的9种 OOM 常见原因及解决方案 堆溢出 这种场景最为常见，报错信息： java.lang.OutOfMemoryError: Java heap space 原因 1.代码中可能存在大对象分配（如大数组） 2.可能存在内存泄漏，多次GC后，仍然无法找到一块足够大的内存容纳当前对象 解决方法 1.对于大对象分配，条件允许的话，可以扩大堆内存的分配空间，是否可以对大对象进行分割 2.对于内存泄漏，可以使用（jmap和jconsole监测），检查代码
omm kill 内存碎片化
最新发布
Pro_jhf的博客
09-08 757
频繁的 OOM 现象确实会导致内存碎片化，碎片化会进一步加剧内存分配的失败，尤其是对于大块内存的分配需求。因此，在 Kylin V10 SP2 系统中，优化内存使用、调整内核参数以及使用内存压缩机制等措施可以有效缓解内存碎片化问题，并减少 OOM 进程被杀的情况。定期监控和优化内存使用状况是保持系统长期稳定的关键，同时应考虑根据应用场景合理配置内核参数、增加物理内存或使用 Huge Pages 来减轻碎片化对系统的影响。
omm server.zip_OMM_OMM SERVER_Server_lineage_lineage server
09-24
【标题】"omm server.zip_OMM_OMM SERVER_Server_lineage_lineage server" 指的是一款名为 OMM 的服务器软件的归档包，其中包含了与 Lineage Server 相关的组件和服务。Lineage Server 通常是指一款大型多人在线角色...
mysql5.7 内存持续_MySQL5.7高版本 疑似内存泄露
weixin_34696129的博客
01-18 411
I have an instance running on mysql-5.7.19. However, I found that its physical memory and virtual memory are both growing slowly. Finally, the mysqld process was killed by Oom-killer.Ok , 说人话。因为历史原因,我...
MySQL OOM（内存溢出）的排查思路及优化方法
MYSQL轻松学的专栏
06-26 1万+
​OOM全称"Out Of Memory"，即内存溢出。 内存溢出已经是软件开发历史上存在了近40年的“老大难”问题。在操作系统上运行各种软件时，软件所需申请的内存远远超出了物理内存所承受的大小，就叫内存溢出。 内存溢出产生原因多种多样，当内存严重不足时，内核有两种选择： 直接panic 杀掉部分进程，释放一些内核。 大部分情况下，会杀掉导致OOM的进程，然后系统恢复。...
odoo17核心概念menu1——主菜单
jiafeitutu的博客
12-21 1834
odoo17核心概念menu1——主菜单
数据库主主同步
weixin_41752427的博客
06-07 704
# 1=================master==================# 设置server-id，两节点必须不一样 server-id = 100 # 开启bin_log，模式为ROW，允许最大日志为1G log_bin = mysql-bin binlog_format = ROW max_binlog_size = 1024M # mysql5.7的版本不需要配置log-slave-updates=1 # log-slave-updates = 1 # 实现数据库宕机恢复后
MYSQL内存请求一直不释放_MySQL内存不释放分析
weixin_33223159的博客
02-18 3282
问题分析场景1 使用sysbench压测数据库场景2 load 一个很大事务的insert语句问题突破测试jemalloc场景1使用sysbench压测数据库场景2 load 一个很大事务的insert语句小结MySQL到底有没有释放内存？通过gdb调试结论线上MySQL数据库发现一些实例，内存使用不断增高，并且当连接数断开后内存不会释放，最终导致的结果是被操作系统OOM问题分析模拟两个场景来分析...
MySQL内存逐渐增长导致数据库挂起-解决方案？
天道酬勤，自强不息
03-17 4875
MySQL内存逐渐增长导致数据库挂起-解决方案？原创 2018-03-17 徐春阳 数据库随笔      Memory usage gradually increases and brings server to halt。      前几天提到发现某系统MySQL数据库内存疑似泄露， 见链接：   在MySQL 5.7.18或以上版本发现疑似内存泄露的现象 。收到一些网友的反馈，他们也都说在使用...
mysql内存占用突然增高_解决MySQL突然占用全部内存的问题
weixin_36320737的博客
01-21 813
前段时间落格从虚拟主机迁移到了独立的vps上，这下所有的维护内容都得我自己动手了。为了性能，另外既然能自己配环境了，自然不会用旧的配置。我用了 Ubuntu Server 16.04 + PHP 7.0 + Nginx + MySQL 5.7 总之，踩了不少的坑。现在，来记录一下关于 MySQL 为什么会突然占满内存一开始我以为是vps遭到了攻击，可是只查看网卡流量就不是这么回事。第一次死机，我以...
排查--[MySQL8.X 所占内存越来越大] 思路
Mr.ACO的专栏
03-20 2332
MYSQL 内存性能问题 优化 思路
      GTID入门篇
weixin_40524659的博客
04-06 676
GTID入门篇 GTID是全局事物标识符，是mysql5.6版本在主从复制方面推出的重量级特性。有了gtid，一个事物在集群中就不在孤独，在每一个节点中，都存在具有相同标识符的兄弟们和它作伴，同一个事物中就不在孤独，在每一个节点中，都存在具有相同标识符的兄弟们和它作伴，同一个事物，在同一个节点中出现多次的情况，也不会重现了，gtid的出现，直...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值