MySQL⾃动清理binlog⽇志的⽅法
说明：
开启MySQL binlog⽇志的服务器，如果不设置⾃动清理⽇志，默认binlog⽇志⼀直保留着，时间⼀长，服务器磁盘空间被binlog⽇志占满，导致MySQL数据库出错。
使⽤下⾯⽅法可以安全清理binlog⽇志
⼀、没有主从同步的情况下清理⽇志
mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL 5 DAY)';
#mysql 定时清理5天前的binlog
mysql -u root -p  #进⼊mysql 控制台
reset master;  #重置binlog
⼆、MySQL主从同步下安全清理binlog⽇志
1、mysql  -u root -p  #进⼊从服务器mysql控制台
show slave status\G;  #检查从服务器正在读取哪个⽇志，有多个从服务器，选择时间最早的⼀个做为⽬标⽇志。
2、进⼊主服务器mysql控制台
show master log;  #获得主服务器上的⼀系列⽇志
PURGE MASTER LOGS TO 'binlog.000058';  #删除binlog.000005之前的，不包括binlog.000058
PURGE MASTER LOGS BEFORE '2016-06-22 13:00:00';  #清除2016-06-22 13:00:00前binlog⽇志
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);  #清除3天前binlog⽇志
三、设置⾃动清理MySQL binlog⽇志
vi  /etc/myf  #编辑配置
expire_logs_days = 15 #⾃动删除15天前的⽇志。默认值为0，表⽰从不删除。
log-bin=mysql-bin #注释掉之后，会关闭binlog⽇志
binlog_format=mixed #注释掉之后，会关闭binlog⽇志
:wq!  #保存退出
扩展阅读：
mysql> help purge;
Name: 'PURGE BINARY LOGS'
Description:
Syntax:
PURGE { BINARY | MASTER } LOGS
{ TO 'log_name' | BEFORE datetime_expr }
The binary log is a set of files that contain information about data
modifications made by the MySQL server. The log consists of a set of
binary log files, plus an index file (see
The PURGE BINARY LOGS statement deletes all the binary log files listed
in the log index file prior to the specified log file name or date.
BINARY and MASTER are synonyms. Deleted log files also are removed from
the list recorded in the index file, so that the given log file becomesmysql删除重复的数据保留一条
the first in the list.
This statement has no effect if the server was not started with the
--log-bin option to enable binary logging.
Examples:
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
下⾯是其它⽹友给出的⽅法，⼤家可以参考⼀下
MYSQL主从复制(replication)采⽤ RBR 模式后，binlog的格式为"ROW"，能解决很多原先出现的主键重复问题。在⼀个繁忙的master db server上，binlog⽇志⽂件增长速度很快，如果不定时清除，硬盘空间很快就会被充满。设置⾃动清理mysql binlog⽇志，配置myf：
expire_logs_days = 10
在运⾏时修改：
show binary logs;
show variables like '%log%';
set global expire_logs_days = 10;
清除之前可以采⽤相应的备份策略。
⼿动删除10天前的MySQL binlog⽇志：
PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);
show master logs;
MASTER和BINARY是同义词。
附：关于MYSQL复制的⼏种模式
从 MySQL 5.1.12 开始，可以⽤以下三种模式来实现：
– 基于SQL语句的复制(statement-based replication, SBR)，
– 基于⾏的复制(row-based replication, RBR)，
– 混合模式复制(mixed-based replication, MBR)。
相应地，binlog的格式也有三种：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默认的。
在运⾏时可以动态改动 binlog的格式，除了以下⼏种情况：
. 存储流程或者触发器中间
. 启⽤了NDB
. 当前会话试⽤ RBR 模式，并且已打开了临时表
如果binlog采⽤了 MIXED 模式，那么在以下⼏种情况下会⾃动将binlog的模式由 SBR 模式改成 RBR 模式。
. 当DML语句更新⼀个NDB表时
. 当函数中包含 UUID() 时
. 2个及以上包含 AUTO_INCREMENT 字段的表被更新时
. ⾏任何 INSERT DELAYED 语句时
. ⽤ UDF 时
. 视图中必须要求运⽤ RBR 时，例如建⽴视图是运⽤了 UUID() 函数
设定主从复制模式：
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"
也可以在运⾏时动态修改binlog的格式。例如
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';
两种模式各⾃的优缺点：
SBR 的优点：
历史悠久，技能成熟
binlog⽂件较⼩
binlog中包含了所有数据库修改信息，可以据此来审核数据库的安全等情况
binlog可以⽤于实时的还原，⽽不仅仅⽤于复制
主从版本可以不⼀样，从服务器版本可以⽐主服务器版本⾼
SBR 的缺点：
不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
调⽤具有不确定因素的 UDF 时复制也可能出疑问
运⽤以下函数的语句也不能被复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除⾮启动时启⽤了 –sysdate-is-now 选项)
INSERT … SELECT 会产⽣⽐ RBR 更多的⾏级锁
复制须要执⾏全表扫描(WHERE 语句中没有运⽤到索引)的 UPDATE 时，须要⽐ RBR 请求更多的⾏级锁
对于有 AUTO_INCREMENT 字段的 InnoDB表⽽⾔，INSERT 语句会阻塞其他 INSERT 语句
对于⼀些复杂的语句，在从服务器上的耗资源情况会更严重，⽽ RBR 模式下，只会对那个发⽣变化的记录产⽣影响
存储函数(不是存储流程 )在被调⽤的同时也会执⾏⼀次 NOW() 函数，这个可以说是坏事也可能是好事
确定了的 UDF 也须要在从服务器上执⾏
数据表必须⼏乎和主服务器保持⼀致才⾏，否则可能会导致复制出错
执⾏复杂语句如果出错的话，会消耗更多资源
RBR 的优点：
任何情况都可以被复制，这对复制来说是最安全可靠的
和其他⼤多数数据库系统的复制技能⼀样
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
复制以下⼏种语句时的⾏锁更少：
* INSERT … SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
执⾏ INSERT，UPDATE，DELETE 语句时锁更少
从服务器上采⽤多线程来执⾏复制成为可能
RBR 的缺点：
binlog ⼤了很多
复杂的回滚时 binlog 中会包含⼤量的数据
主服务器上执⾏ UPDATE 语句时，所有发⽣变化的记录都会写到 binlog 中，⽽ SBR 只会写⼀次，这会导致频繁发⽣ binlog 的并发写疑问
UDF 产⽣的⼤ BLOB 值会导致复制变慢
不能从 binlog 中看到都复制了写什么语句(加密过的)
当在⾮事务表上执⾏⼀段堆积的SQL语句时，最好采⽤ SBR 模式，否则很容易导致主从服务器的数据不⼀致情况发⽣
另外，针对系统库 mysql ⾥⾯的表发⽣变化时的处理准则如下：
如果是采⽤ INSERT，UPDATE，DELETE 直接操作表的情况，则⽇志格式根据 binlog_format 的设定⽽记录
如果是采⽤ GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么⽆论如何都采⽤ SBR 模式记录。
注：采⽤ RBR 模式后，能处理很多原先出现的主键重复问题。实例:
对于insert into db_allot_ids select * from db_allot_ids 这个语句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG⽇志信息为:
—————————————–
BEGIN
/*!*/;
# at 173
#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
insert into db_allot_ids select * from db_allot_ids
/
*!*/;
—————————————–
在BINLOG_FORMAT=ROW 模式下:
BINLOG⽇志信息为:
—————————————–
BINLOG '
hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;
—————————————–
清理⽇志步骤
1.查⽇志档案
mysql> show binary logs;
+----------------+-----------+
| Log_name      | File_size |
+----------------+-----------+
| ablelee.000001 | 150462942 |
| ablelee.000002 |      125 |
| ablelee.000003 |      106 |
+----------------+-----------+
2.删除bin-log(删除ablelee.000003之前的⽽没有包含ablelee.000003)
mysql> purge binary logs to 'ablelee.000003';
Query OK, 0 rows affected (0.16 sec)
3.  查询结果(现在只有⼀条记录了.)
mysql> show binlog events\G
*************************** 1. row ***************************
Log_name: ablelee.000003
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 106
Info: Server ver: 5.1.26-rc-log, Binlog ver: 4
1 row in set (0.01 sec)
(ablelee.000001和ablelee.000002已被删除)
mysql> show binary logs;
+----------------+-----------+
| Log_name      | File_size |
+----------------+-----------+
| ablelee.000003 |      106 |
+----------------+-----------+
1 row in set (0.00 sec)
(删除的其它格式运⽤!)
  PURGE {MASTER | BINARY} LOGS TO 'log_name'
  PURGE {MASTER | BINARY} LOGS BEFORE 'date'
  ⽤于删除列于在指定的⽇志或⽇期之前的⽇志索引中的所有⼆进制⽇志。这些⽇志也会从记录在⽇志索引⽂件中的清单中被删除，这样被给定的⽇志成为第⼀个。
  例如：
  PURGE MASTER LOGS TO 'mysql-bin.010';
  PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00';
清除3天前的 binlog
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);
  BEFORE变量的date⾃变量可以为'YYYY-MM-DD hh:mm:ss'格式。MASTER和BINARY是同义词。
  如果您有⼀个活性的从属服务器，该服务器当前正在读取您正在试图删除的⽇志之⼀，则本语句不会起作⽤，⽽是会失败，并伴随⼀个错误。不过，如果从属服务器是休⽌的，并且您碰巧清理了其想要读取的⽇志之⼀，则从属服务器启动后不能复制。当从属服务器正在复制时，本语句可以安全运⾏。您不需要停⽌它们。
  要清理⽇志，需按照以下步骤：
  1. 在每个从属服务器上，使⽤SHOW SLAVE STATUS来检查它正在读取哪个⽇志。
  2. 使⽤SHOW MASTER LOGS获得主服务器上的⼀系列⽇志。
  3. 在所有的从属服务器中判定最早的⽇志。这个是⽬标⽇志。如果所有的从属服务器是更新的，这是清单上的最后⼀个⽇志。
  4. 制作您将要删除的所有⽇志的备份。（这个步骤是⾃选的，但是建议采⽤。）
  5. 清理所有的⽇志，但是不包括⽬标⽇志

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。