mysql正确清理binlog日志的方法

MySQL中的binlog日志记录了数据库中数据的变动，便于对数据的基于时间点和基于位置的恢复，但是binlog也会日渐增大，占用很大的磁盘空间，因此，要对binlog使用正确安全的方法清理掉一部分没用的日志。

 

[方法一]手动清理binlog

清理前的准备：

1.查看主库和从库正在使用的binlog是哪个文件

show master status
show slave status\G

2.在删除binlog日志之前，首先对binlog日志备份，以防万一 

开始手动清除binlog，删除指定日期以前的日志

purge master logs before '2016-09-01 17:20:00'; //删除指定日期以前的日志索引中binlog日志文件

或

purge master logs to'mysql-bin.000022'; //删除指定日志文件的日志索引中binlog日志文件

#将指定时间之前的日志清理

purge binary logs before '2018-02-01 12:00:00';

#将指定日志文件之前的日志清除，不包括指定的日志文件

purge binary logs to 'mysql-bin.000003';

 

注意：使用该语法，会将对应的文件和mysql-bin.index中对应路径删除

时间和文件名一定不可以写错，尤其是时间中的年和文件名中的序号，以防不下心将正在使用的binlog删除！！！切勿删除正在使用的binlog

 

补充：(参考 https://www.aliyun.com/jiaocheng/1405382.html)

• reset master:将删除日志索引文件中记录的所有binlog文件，创建一个新的日志文件，起始值从000001开始。不要轻易使用该命令，这个命令通常仅仅用于第一次用于搭建主从关系的时的主库。
• reset slave:清除master.info文件、relay-log.info文件，以及所有的relay log文件,并重新启用一个新的relaylog文件

使用reset slave之前必须使用stop slave 命令将复制进程停止。

 

[方法二]通过设置binlog过期时间，使系统自动删除binlog文件

 

1.在mysql中修改

查看binlog过期时间，这个值默认是0天，也就是说不自动清理，可以根据生产情况修改，本例修改为7天

 

mysql> show variables like 'expire_logs_days'; 

+------------------------+-------+ 

| Variable_name  | Value | 

+------------------------+-------+ 

| expire_logs_days |   0  | 

+------------------------+-------+ 

mysql> set global expire_logs_days = 7;    #设置binlog多少天过期

 

设置之后不会立即清除，触发条件是以下之一：

1.binlog大小超过max_binlog_size，max_binlog_size默认为1G

 

2.手动执行flush logs

 

如果binlog非常多，不要轻易设置该参数，有可能导致IO争用，这个时候可以使用purge命令予以清除：

将bin.000055之前的binlog清掉:

mysql>purge binary logs to 'bin.000055';

将指定时间之前的binlog清掉:

mysql>purge binary logs before '2017-05-01 13:09:51';

 

 

2.在配置文件my.cnf中修改

mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前日志大小达到max_binlog_size,还会自动创建新的二进制日志。如果你正则使用大的事务，二进制日志还会超过max_binlog_size:事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

 

expire_logs_days :定义了mysql清除过期日志的时间。默认值为0,表示“没有自动删除”。

max_binlog_size：二进制日志最大大小，如果二进制日志写入的内容超出给定值，日志就会发生滚动。你不能将该变量设置为大于1GB或小于4096字节。 默认值是1GB。

 

在my.cnf中添加配置,设置过期时间为30天

expire_logs_days = 30

max_binlog_size使用默认值即可

 

注意：

过期时间设置的要适当，对于主从复制，要看从库的延迟决定过期时间，避免主库binlog还未传到从库便因过期而删除，导致主从不一致！！！

 

 

MySql自动清除binary logs日志

1.背景
某个项目为了实现通过Canal将MySql自动同步至Redis的目的，开启了MySql的log-bin模式（binary-log，二进制日志）。开启方式很简单，这里只是给出初步介绍：

//关闭MySql服务

//vi /etc/my.cnf

[mysqld]
...
log-bin=mysql-bin
...

//开启MySql服务
1
2
3
4
5
6
7
8
9
10
开启了二进制日志后，我们确实实现了Redis的自动同步。但是后来发现服务器磁盘空间暴减，通过分析发现是MySql产生了大量二进制文件，如下：

[root@localhost mysql]# ls -1
ibdata1
ib_logfile0
ib_logfile1
ib_logfile0
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
...
mysql-bin.index
...
1
2
3
4
5
6
7
8
9
10
11
12
我分配给MySql的磁盘空间只有20G，经常会一两天就产生MySql磁盘爆满导致MySql服务不可用的问题。
然后我就开始了悲催的MySql日志清理之旅。

2.第一种策略：手动清理
刚开始都是通过手动进行清理。
通常这么做：

#将指定时间之前的日志清理
purge binary logs before '2018-02-01 12:00:00';

#将指定日志文件之前的日志清除
purge binary logs to 'mysql-bin.000003';
1
2
3
4
5
这么做一直都能达到清理的目的，就是过几天就需要清理一次，很是繁琐。
但是因为工期紧，任务重，我也没花时间了解别的方式，直到有一天…

有一天，开启了MySql的主从模式，然后照例通过purge进行日志清理。
刚开始也是没有问题的，然后，有一次执行了purge之后就没有然后了：MySql直接被玩坏了…

后来分析，应该是我们清理日志的时刻，正巧与主从复制冲突了，然后就出错了。
冲突的原因我没有深究，但是大概有可能如下：

恰巧试图清除正在被从服务器读取的日志，清除失败
恰巧清除了从服务器想要读取的日志，清除成功，但是从服务器不能再复制
最后，经过一番研究，通过flush logs + restart解决了问题。

3.第二种策略：自动清理
考虑到purge的不稳定性以及天天清理日志的烦恼，后来采取了自动清理策略。实现方法如下：

一次性的（不推荐：因为服务重启，配置失效）：

SQL > set global expire_logs_days = 3;
1
一劳永逸（就是改配置，推荐）：

//关闭MySql服务

//vi /etc/my.cnf
[mysqld]
...
#开启binary log
log-bin=mysql-bin

#日志超过3天自动过期
expire_logs_days = 3
...

//开启MySql服务
————————————————
版权声明：本文为CSDN博主「hanchao5272」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/hanchao5272/article/details/79227325