AMH面板mysql-bin日志文件占用硬盘资源处理方法

 

里要分享AMH面板(免费4.2版本),MYSQL-BIN占用资源过大解决方法。

| mysql-bin.000280 | 104857695 |
| mysql-bin.000281 | 104857974 |
| mysql-bin.000282 | 104857873 |
| mysql-bin.000283 | 104857787 |
| mysql-bin.000284 | 104857778 |
| mysql-bin.000285 | 104857901 |
| mysql-bin.000286 | 104857999 |
| mysql-bin.000287 | 104857860 |
| mysql-bin.000288 | 104857698 |
| mysql-bin.000289 | 104857773 |
| mysql-bin.000290 | 104857751 |
| mysql-bin.000291 | 104857741 |
| mysql-bin.000292 | 104857926 |
| mysql-bin.000293 | 104857693 |
| mysql-bin.000294 | 104857684 |

我们可以看到31日短短 几个小时,缓存资源就占用到几个G,如果照这样下去,基本的VPS硬盘,不要几个小时或者2天,就会直接占满。我们肯定要解决这个问题才可以。

第一、清理现有MYSQL-BIN文件

最好不要直接删除,可能会导致MYSQL启动不了的问题,还是通过下面的方法,登录SSH之后,输入:

 代码如下 复制代码

mysql -u root -p

然后输入数据库密码,然后再输入:

 代码如下 复制代码

reset master;

这样我们缓存MYSQL-BIN就会全部清除。

第二、限制MYSQL-BIN的生成

缓存文件还是有用的,可以用于万一MYSQL出现问题可以用于恢复数据使用,我们只要做好定期维护就可以,但是如果你一定需要禁止他生成,那我们可以下面这样操作。

在/etc/my.cnf找到文件,然后把20行log-bin = mysql-bin用#注释,更新服务器文件。

第三、重启AMH面板MYSQL

 代码如下 复制代码

amh mysql restart

输入上述命令,重启MYSQL就可以搞定我们需要的问题。

总结,一般我们在使用AMH面板或者LNMP的时候大部分用户都不会处理这些问题,只会在网站打不开,数据盘占满之后然后找人 解决。看到这篇文章的方法,即便我们开始不解决问题或者定期维护,在遇到问题后可以自己学会解决MYSQL-BIN占用硬盘问题。

禁止MYSQL日志

/etc/my.cnf

编辑这个文件,找到log-bin=mysql-bin和binlog_format=mixed两行,前面#注释掉就可以。同样的,我们重启MYSQL生效。

时间: 2024-11-08 18:41:25

AMH面板mysql-bin日志文件占用硬盘资源处理方法的相关文章

linux系统中清理MySql的日志文件mysql-bin.00000

首先说明,mysql-bin.00000*类似的文件是mysql的日志文件. 通过命令  代码如下 复制代码 du -h –max-depth=1 / 查看根目录下每个文件夹所占用存储的大小,发现/var占用了快3G,进一步使用du命令,发现是存放mysql数据文件的文件夹占用了绝大部分空间,进入该文件夹,发现有很多mysql-bin.00000开头的文件,而且其中的某些达到了1G以上,google发现原来这些用户是mysql记录的日志文件,用于数据库崩溃后恢复数据和主从数据库进行数据同步的.如

mysql二进制日志文件恢复数据库_Mysql

二进制日志的文件的作用     mysql二进制日志文件用来记录所有用户对数据库操作,即记录用户对数据库操作的sql语句.如果有此文件,当数据库发生意外时,可以通过此文件查看到用户在此文件记录的时间段内用户所做的操作,再和数据库备份配合使用,即可再现用户操作,使数据库恢复. 二进制日志文件的弊端 二进制日志文件开启后,所有对数据库操作的记录均会被记录到此文件, 所以,当长时间开启之后,日志文件会变得很大,占用磁盘空间. 使用二进制日志文件恢复数据库 开启日志文件 mysql默认是不开启日志文件的

MySQL的日志文件概述

这里介绍的日志文件都是MySQL数据库本身的文件,和具体用什么存储引擎无关. 错误日志 MySQL的错误日志类似于Oracle的alert.log,默认情况下以.err结尾,DBA在遇到问题时,首先应该查询 该日志获得错误信息. 查询日志 查询日志记录了所有的数据库请求,即时这些请求没有得到正确 的执行. 慢查询日志 慢查询日志用于记录运行时间比较长的SQL语句,可以通过参数 long_query_time来设置该阀值.默认情况下,MySQL并不启动慢查询日志,可以通过设置log_slow_qu

mysql 删除日志文件命令详解

如果没有主从复制,可以通过reset master的方式,重置数据库日志,清除之前的日志文件:  代码如下 复制代码 mysql> reset master; 还有一各就是在my.cnf里配置.  代码如下 复制代码 expire_logs_days = 3 二进制日志自动删除的天数.这里设置了自动清除3天前的logs. 默认值为0,表示"没有自动删除". 例  代码如下 复制代码 # 按文件:删除mysql-bin.000354之前的日志,不包含mysql-bin.000354

MySQL服务器进程CPU占用100%的解决方法_Mysql

朋友主机(Windows 2003 + IIS + PHP + MYSQL )近来 MySQL 服务进程 (mysqld-nt.exe) CPU 占用率总为 100% 高居不下.此主机有10个左右的 database, 分别给十个网站调用.据朋友测试,导致 mysqld-nt.exe cpu 占用奇高的是网站A,一旦在 IIS 中将此网站停止服务,CPU 占用就降下来了.一启用,则马上上升. MYSQL CPU 占用 100% 的解决过程 今天早上仔细检查了一下.目前此网站的七日平均日 IP 为

sqlserver2005没有log日志文件时恢复数据库的方法

SQLServer2005数据库日志文件损坏的情况下如何恢复数据库呢?下面我们来详细分析... 在某些偶然的情况下, 会引起SQL Server 2005数据库日志文件的损坏,比如:硬件故障.计算机非正常重启或关机. 当SQL Server 2005数据库日志文件损坏时,可能会出现以下情况: 1.在SQL Server Management Studio中显示数据库处于置疑(suspect)状态. 2.事件日志可能会出现如下错误信息:Could not redo log record (2173

联机日志文件损坏后的恢复方法

恢复 昨天遇到一个Oracle数据库的问题,环境是:Windows2000+Oracle9i.使用windows关机重启后,oracle无法连接,当用startup启动时总是报ORA-00333错误,检查Oracle文档对此问题的描述,如下:ORA-00333 redo log read error block string count stringCause: An I/O error occurred while reading the log described in theaccompa

SQL Server非正常删除日志文件(ldf)恢复方法

server|恢复 事务日志文件(ldf)在SQL Server服务未启动的情况下被删除(SQL Server在工作状态下是无法删除日志文件),这种情况下启动SQL服务后,相应数据库即被标志成置疑(suspend)状态 按目前本人实验结果,恢复方法如下:1,分离被置疑的数据库,可以使用sp_detach_db2,附加数据库,可以使用sp_attach_single_file_db SQL2K下可以直接在EM环境下完成这些操作,如果是SQL7则需要在QA里完成操作. 本人在SQL Server20

无数据库日志文件恢复sql server数据库方法两则

    方法一 1.新建一个同名的数据库 2.再停掉sql server(注意不要分离数据库) 3.用原数据库的数据文件覆盖掉这个新建的数据库 4.再重启sql server 5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名) 6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用 数据库的脚本创建一个新的数据库,并将数据导进去就行了. USE MASTERGOSP_CONFIGURE ALLOW UPDATES,1 RECON