记一次生产线MySQL库Binlog日志占满磁盘的故障处理

运维 数据库运维
今天早上监控平台邮件通知生产某业务系统的MySQL数据库存储空间达到了90%,赶紧爬起来远程连上数据库主机,发现Master双主MySQL数据库10.5.11.105、和10.5.11.106数据目录/var/lib/mysql空间使用率达到了97%和96%。

 一、故障描述

今天早上监控平台邮件通知生产某业务系统的MySQL数据库存储空间达到了90%,赶紧爬起来远程连上数据库主机,发现Master双主MySQL数据库10.5.11.105、和10.5.11.106数据目录/var/lib/mysql空间使用率达到了97%和96%。

二、问题分析过程

首先查询确认数据库主从关系

登录10.5.11.105和10.5.11.106数据库,执行语句:show slave status\G; 查看。

 

说明10.5.11.106数据库master-bin.000779之前的binlog是可以清理的。

执行语句:show slave hosts \G 查看server id。

 

说明Server_id:33333是10.5.11.105的从库。

执行语句:show variables like ‘server_id’可以确认。

三、查询binlog自动清理是否开启

执行如下语句show variables like 'expire_logs_days';

查看参数发现binlog自动清理功能没有开启。

 

四、查看具体的binlog文件

执行语句:show binary logs;

可以看到有大量的binlog文件。

记一次生产线MySQL库binlog日志占满磁盘的故障处理

五、查看binlog具体的存放路径

执行语句:show variables like '%log_bin_basename%'; 查看。

 

六、问题的根本原因

经过排查,我们发现问题的根本原因在于没有开启binlog自动清理功能,导致有大量的binlog进行积压所致。

七、处理问题

清理binlog文件。通过确认主从应用最新的binlog来清理binlog,使用如下命令,清理的时候可以多留几个binlog,注意不要手动rm binlog文件。

1、Purge binary logs to_’binlog文件名’;来清理binlog日志。

2、开启自动清理binlog日志功能(主从库都需执行)

执行语句:

set global expire_logs_days=10;

并在/etc/my.cnf的配置文件中增加如下配置:

expire_logs_days=10

注意:binlog日志过期时间可根据自己公司的要求自定义,我这里设置的是10天!

 

责任编辑:姜华 来源: 今日头条
相关推荐

2020-12-15 11:18:43

系统磁盘lvm数据库

2022-06-01 06:17:42

微服务Kafka

2018-07-18 15:37:24

数据库DB2故障处理

2019-11-18 13:42:55

MySQL数据库迁移

2018-12-06 16:25:39

数据库服务器线程池

2019-12-27 10:43:48

磁盘数据库死锁

2019-07-25 08:30:58

数据库服务器故障

2019-08-19 01:34:38

数据库SQL数据库优化

2021-03-01 06:14:50

环境高并发延迟

2020-11-03 07:34:12

Kafka后端工程师

2019-11-22 08:05:01

数据库mysql分区

2019-12-12 10:38:10

mysql数据库nnodb

2020-09-25 07:57:42

生产事故系统

2019-09-08 17:52:10

数据库log file sy等待事件

2019-09-05 09:17:37

MySQL数据库线程

2019-09-27 17:24:26

数据库优化sql

2019-12-16 07:18:42

数据库SQL代码

2019-01-21 11:17:13

CPU优化定位

2021-12-06 17:21:05

异常报错故障

2019-08-15 11:30:06

SQL数据库ASH
点赞
收藏

51CTO技术栈公众号