首页 > 数据库 > SQL Server > 正文

mysql 设置 log 保留天数

2019-11-03 08:35:16
字体:
来源:转载
供稿:网友
现象:数据库除了查询以外的其他操作都失败,报错信息为:got error 28 from storage engin
原因:执行df命令,看到系统根目录(/)的剩余空间是0,使用率达到了100%,原来是系统没有任何空间了。
查找罪魁祸首:

1、查找下,数据主要“堆积”在哪里
cd /
du -m --max-depth=1 -k
看到/usr用掉了绝大多数的空间,继续深入进去
cd /usr
du -m --max-depth=1 -k
看到是local占了大头
cd local
du -m --max-depth=1 -k
这次是MySQL,果然没错,是mysql自己消耗掉了很大一部分磁盘空间,那到这个时候,猜也猜到,一定是mysql下的data占用了空间,一看,果然是。
其实这个时候,症结已经差不多找出来了,但是这个时候会出现两种情况,对于不同的情况,解决的办法也不相同:

2、在data目录,如果出现了很多mysql-bin.000****的文件,而且占用空间很大,那这里就要处理下。
mysql-bin.000***文件是mysql的操作日志文件,里面记录这这个数据库所有的数据操作(插入,更新,删除等)的记录,而且如果没有相关的管理,这些文件是不会自己删除的,只会越来越多,最后把磁盘给塞满。
其实,对于一般用途的mysql数据库,我们对数据恢复阿,历史操作查找阿什么都不会太在意,那么这些日志文件保留太长时间的,意义也不大,还不如删掉一些老的日志文件,来为系统留下大量的空间。
我们只要在配置文件/etc/my.cnf里添加下面这一句就行了:expire_logs_days=n就行了,“n”就是保留最近“几天”的日志信息,之前的就都删掉。

3、如果不是2的问题,那我们可以故技重施,看看data下面是哪个数据库的目录占用空间过大,找到这个数据库,cd进去,ll一下,可以看到这里存放着这个数据库的所有表信息,一般一个表由三个文件组成:
TABLENAME.frm: 表结构文件
TABLENAME.MYD: 表数据文件
TABLENAME.MYI:表结构和数据的索引文件
可以想到,如果一张表的记录很多,那么TABLENAME.MYD就一定会很大。
如果没有其他办法了,一定要删除这个表的数据,数据库才能恢复,那删除的步骤如下:
删除TABLENAME.MYD,再重建一个空的文件TABLENAME.MYD,数据库重启,登录到mysql,进入相应的数据库,执行delete from TABLENAME,这样就可以了。
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表