mysql的binlog太大太多占用大量磁盘

现象:网站访问越来越慢,最后无法访问了,经过检查发现磁盘满了。仔细查询下来确认是由于mysql的binlog太多太大占用了空间。

分析过程及解决方案:通常出现这种问题都应该登录服务器检查磁盘、内存和进程使用的情况,通过top、df –h和free –m来检查,发现磁盘空间满了。再进一步通过du –sh对可以的目录进行检查,发现是mysql的binlog占用空间过大。清理binlog的方法如下:

  1. 设置日志保留时长expire_logs_days自动删除

查看当前日志保存天数:

show variables like '%expire_logs_days%';

这个默认是0,也就是logs不过期,可通过设置全局的参数,使他临时生效:

set global expire_logs_days=7;

设置了只保留7天BINLOG, 下次重启mysql这个参数默认会失败,所以需在my.cnf中设置

expire_logs_days = 7

  1. 手动删除BINLOG (purge binary logs)

用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件

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';

PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);

点赞
收藏

评论区

加载中...

相关推荐

MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1

文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s

Oracle 分组与拼接字符串同时使用

SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(

Python3:sqlalchemy对mysql数据库操作,非sql语句

Python3:sqlalchemy对mysql数据库操作,非sql语句python3authorlizmdatetime2018020110:00:00coding:utf8'''

MySQL 磁盘满了,怎么办??

问题使用命令发现磁盘使用率为100%了,还剩几十兆。一系列神操作:备份数据库,删除实例、删除数据库表、重启mysql服务.结果磁盘空间均为释放怎么办网上查了很多资源,说要进行磁盘碎片化整理。原因是datafree占据的空间太多啦。具体可以通过这个sql查看。SELECTCONCAT(TRUNCATE(S

Twitter的分布式自增ID算法snowflake (Java版)

概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移

MongoDB oplog 深入剖析

MongoDB的Replication是通过一个日志来存储写操作的,这个日志就叫做oplog。在默认情况下,oplog分配的是5%的空闲磁盘空间。通常而言,这是一种合理的设置。可以通过mongodoplogSize来改变oplog的日志大小。oplog是cappedcollection,因为oplog的特点(不能太多把磁盘填满了,固定大小)需要