Mysql binlog 无法删除(purge命令无法删除)

本文介绍了一次解决MySQL服务器上无法删除binlog的问题经历,包括问题现象、原因分析及最终解决方案。

1.版本

1)操作系统

cat /etc/issue
CentOS release 6.6 (Final)
Kernel \r on an \m

cat /proc/version
Linux version 2.6.32-504.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Oct 15 04:27:16 UTC 2014

2)mysql数据库版本

MySQL --version

MySQL  Ver 14.14 Distrib 5.6.26, for linux-glibc2.5 (x86_64) using  EditLine wrapper

2. 问题描述

2.1 发现问题

  今天研发跟我反映他们有一套测试库,mysql 的binlog删除不了(他使用的是purge命令做日志删除)。登录发现binlog  占了将近70个G,保存了最近一周的日志:

 

ls -rlt 3306-bin*
-rw-rw---- 1 mysql mysql 1074477734 Jan  9 19:55 3306-bin.000049
-rw-rw---- 1 mysql mysql 1074023126 Jan  9 21:15 3306-bin.000050
......
......
-rw-rw---- 1 mysql mysql  859308032 Jan 16 19:49 3306-bin.000107
-rw-rw---- 1 mysql mysql       2478 Jan 17 09:19 3306-bin.index

查看数据库的expire_logs_days参数,发现是7,然后我设置该参数为1,并进行 flush logs操作(正常情况下,会删除1天以前的所有binlog)

 

 

mysql> set global expire_logs_days=1;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 1     |
+------------------+-------+
1 row in set (0.00 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.00 sec)

但是执行后我发现,结果并未像我预想的那样,所有的binlog都还在,这是怎么回事?难道这些binlog没有记录在该实例中?查看了3306-bin.index文件,发现这些binlog文件都是记录在 binlog 的index 文件中的,然后在实例上执行showbinary logs; 发现报如下错误:

 

 

mysql> show binary logs;
ERROR 1381 (HY000): You are not using binary logging

报错说我没有使用 binlog,但是我查看参数,该实例确实是打开了binlog:

 

 

mysql> show variables like '%log_bin%';
+---------------------------------+------------------------------------------+
| Variable_name                   | Value                                    |
+---------------------------------+------------------------------------------+
| log_bin                         | ON                                       |
| log_bin_basename                | /data/mysql/mysql3306/log/3306-bin       |
| log_bin_index                   | /data/mysql/mysql3306/log/3306-bin.index |
| log_bin_trust_function_creators | ON                                       |
| log_bin_use_v1_row_events       | OFF                                      |
| sql_log_bin                     | ON                                       |
+---------------------------------+------------------------------------------+
6 rows in set (0.00 sec)

看看error 日志有没有什么信息:

 

 

2018-01-16 19:15:41 6886 [Warning] Disk is full writing '/data/mysql/mysql3306/log/3306-bin.000107' (Errcode: 28 - No space left on device). Waiting for someone to free space...
2018-01-16 19:15:41 6886 [Warning] Retry in 60 secs. Message reprinted in 600 secs
2018-01-16 19:15:44 6886 [ERROR] Error writing file '/data/mysql/mysql3306/log/slow3306.log' (errno: 1 - No space left on device)
2018-01-16 19:25:41 6886 [Warning] Disk is full writing '/data/mysql/mysql3306/log/3306-bin.000107' (Errcode: 28 - No space left on device). Waiting for someone to free space...
2018-01-16 19:25:41 6886 [Warning] Retry in 60 secs. Message reprinted in 600 secs
2018-01-16 19:35:41 6886 [Warning] Disk is full writing '/data/mysql/mysql3306/log/3306-bin.000107' (Errcode: 28 - No space left on device). Waiting for someone to free space...
2018-01-16 19:35:41 6886 [Warning] Retry in 60 secs. Message reprinted in 600 secs
2018-01-16 19:36:41 6886 [Warning] Disk is full writing '/data/mysql/mysql3306/log/3306-bin.000107' (Errcode: 28 - No space left on device). Waiting for someone to free space...
2018-01-16 19:36:41 6886 [Warning] Retry in 60 secs. Message reprinted in 600 secs
2018-01-16 19:46:41 6886 [Warning] Disk is full writing '/data/mysql/mysql3306/log/3306-bin.000107' (Errcode: 28 - No space left on device). Waiting for someone to free space...
2018-01-16 19:46:41 6886 [Warning] Retry in 60 secs. Message reprinted in 600 secs
2018-01-16 19:49:41 6886 [ERROR] An error occured during flushing cache to file. 'binlog_error_action' is set to 'IGNORE_ERROR'. Hence turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.

我们看到昨天下午7点/data 目录下磁盘满了,然后刷数据到磁盘的操作失败,并且binlog_error_action参数使用的默认值(IGNORE_ERROR)。所以自动关闭了binlog(所以 我们上面执行 show binary logs时报错说 你没有使用binlog)。

 

 

3.解决方案
解决方案其实上面error log中已经给我们,我们需要重启实例,来重新启用binlog,然后再删除binlog(purge 或者 flush logs)。当然做这些操作时我们数据目录磁盘是不能被占满的,需要有一定的空间(可以通过删除或者清空一些无关紧要的文件来释放一些空间),否则数据库实例可能停不掉(因为没有空间写日志)

重启实例后我们执行 show binary logs; ,我们看到此时能够正常看到当前实例下所有未被删除的binlog

 

mysql> show binary logs;
+-----------------+------------+
| Log_name        | File_size  |
+-----------------+------------+
| 3306-bin.000054 | 1073745018 |
| 3306-bin.000055 | 1073741931 |
| 3306-bin.000056 | 1073742629 |
| 3306-bin.000057 | 1073742391 |
| 3306-bin.000058 | 1073741974 |
| 3306-bin.000059 | 1073742197 |
| 3306-bin.000060 | 1074293707 |
| 3306-bin.000061 | 1074318524 |
| 3306-bin.000062 | 1074196194 |
| 3306-bin.000063 | 1073957987 |
| 3306-bin.000064 | 1074045715 |
| 3306-bin.000065 | 1074456116 |
| 3306-bin.000066 | 1074352906 |
| 3306-bin.000067 | 1073745429 |
| 3306-bin.000068 | 1089211613 |
| 3306-bin.000069 | 3264774138 |
| 3306-bin.000070 | 1073743716 |
| 3306-bin.000071 | 1074132057 |
| 3306-bin.000072 | 1074296041 |
| 3306-bin.000073 | 1073865674 |
| 3306-bin.000074 | 1074128306 |
| 3306-bin.000075 | 1693579796 |
| 3306-bin.000076 | 1073918285 |
| 3306-bin.000077 | 1074052487 |
| 3306-bin.000078 | 1074118960 |
| 3306-bin.000079 | 1074426059 |
| 3306-bin.000080 | 1092942370 |
| 3306-bin.000081 | 1073817857 |
| 3306-bin.000082 | 1074191946 |
| 3306-bin.000083 | 1074310368 |
| 3306-bin.000084 | 1073810038 |
| 3306-bin.000085 | 1074093671 |
| 3306-bin.000086 | 1074359248 |
| 3306-bin.000087 | 1073741978 |
| 3306-bin.000088 | 1074433324 |
| 3306-bin.000089 | 1073839559 |
| 3306-bin.000090 | 1074001883 |
| 3306-bin.000091 | 1074115966 |
| 3306-bin.000092 | 1074141865 |
| 3306-bin.000093 | 1074028550 |
| 3306-bin.000094 | 1074057515 |
| 3306-bin.000095 | 1074384113 |
| 3306-bin.000096 | 1073786087 |
| 3306-bin.000097 | 1074062101 |
| 3306-bin.000098 | 1074039304 |
| 3306-bin.000099 | 1073871663 |
| 3306-bin.000100 | 1074377569 |
| 3306-bin.000101 | 1367597993 |
| 3306-bin.000102 | 3076703855 |
| 3306-bin.000103 | 2959674341 |
| 3306-bin.000104 | 2960788209 |
| 3306-bin.000105 | 2960786610 |
| 3306-bin.000106 | 1073742076 |
| 3306-bin.000107 |  859308032 |
| 3306-bin.000108 |        120 |
+-----------------+------------+

执行 purge logs 或者 flush logs(要先设置expire_logs_days参数)命令删除日志

 

 


 

 

<think>首先,用户的问题是关于MySQL中清除binlog的方法和注意事项。用户明确表示想查找关于清除binlog的相关信息,如操作方法、注意事项等。 我需要参考系统提供的引用: - 引用[1]:提到清理binlog日志的注意事项,包括备份的重要性,以及设置保留时间后MySQL自动清理- 引用[2]:讨论Binlog在数据恢复中的作用,但不直接相关到清除方法。 - 引用[3]:详细介绍mysql删除binlog的注意事项,包括主从架构下的风险,以及清除命令的安全操作建议。 - 引用[4]:提供具体的清除方法,如设置保留时间、flush logs、purge binary logs等命令。 我的回答需要基于这些引用,但用户说“上述引用仅供参考,并不是用户真正的需求”,我应该尽可能参考用户上一次的问题和我的回答。用户上一次的问题是“我想查找关于MySQL中清除binlog的相关信息”,所以我要直接回答这个。 系统级指令要求: - 所有行内数学表达式使用$...$格式:由于这不是数学主题,可能不需要。 - 独立公式使用$$...$$格式:同样,不适用。 - LaTeX语法正确:确保任何数学表达正确,但这里可能没有。 - 使用中文回答:整个回答用中文。 - 生成相关问题:在回答末尾添加相关问题。 - 引用的段落末尾添加引用标识:例如[^1]。 结构:回答应该清晰、逐步解决问题。包括操作方法和注意事项。 从引用中提炼关键信息: - **操作方法**: - 设置binlog日志保留时间:MySQL自动清理旧文件。[^1] - 手动清除: - flush logs; 清除日志。[^4] - purge binary logs to 'filename'; 删除指定文件前的所有日志。[^3][^4] - purge binary logs before 'datetime'; 删除指定时间前的日志。[^4] - **注意事项**: - 备份重要日志文件。[^1] - 在主从架构下,确保复制安全:如果复制进行中,清理可能失败;如果复制停止,删除未读取日志会导致复制失败。[^3] - 建议操作步骤:避免在生产环境中直接删除。[^3] 我的回答结构: 1. **引言**:简要介绍binlog清除的目的和方法。 2. **操作方法**:详细列出清除方法。 3. **注意事项**:强调风险和最佳实践。 4. **结论**:总结建议。 最后,添加相关问题。 引用标识:在每个关键点后添加引用标识。 例如: - 设置保留时间后,MySQL自动清理旧日志[^1]。 - 手动清除命令purge binary logs before 'datetime'[^4]。 相关问题:生成3-4个相关问题。 可能的生成问题: 1. 如何设置binlog的保留时间? 2. binlog清除对MySQL性能有什么影响? 3. 在主从复制环境中,如何安全清除binlog? 4. binlog清除后如何恢复数据? 确保回答真实可靠:基于提供的引用,但我也知道MySQL文档支持这些。 最终回答格式: - 用中文。 - 清晰段落。 - 引用的地方加[^n]。 - 最后加相关问题。 </think>### MySQL清除binlog的方法和注意事项 MySQLbinlog(二进制日志)用于记录数据库的所有更改操作,在高可用性和数据恢复中至关重要(例如,在数据丢失时通过回放binlog恢复数据[^2])。然而,随着时间推移,binlog文件可能累积占用大量磁盘空间,因此需要定期清除。清除操作包括自动和手动方法,但错误操作可能导致数据一致性丢失或主从复制中断。以下基于MySQL的最佳实践,我将逐步介绍清除binlog的具体操作方法和关键注意事项。操作前,请确保MySQL版本支持相关命令(如MySQL 5.6以上),并建议在测试环境中验证后再应用于生产环境。 #### 一、操作方法 清除binlog主要有两种方式:自动清除(推荐)和手动清除。自动清除基于设置参数实现MySQL后台管理,而手动清除通过SQL命令直接操作文件。 1. **自动清除(推荐)** 您可以设置binlog的过期时间,MySQL会自动清理超过该期限的旧文件。这避免了手动干预的风险。设置方法如下: -MySQL配置文件(如`my.cnf`或`my.ini`)中添加或修改以下参数: ``` expire_logs_days = 7 # 设置binlog保留天数,例如保留7天 ``` 修改后重启MySQL服务生效。 - 或者,在不重启服务的情况下,通过SQL命令动态设置: ```sql SET GLOBAL expire_logs_days = 7; ``` 设置后,MySQL会在后台定期检查并删除超过7天的binlog文件[^1][^4]。这种方式安全高效,适合大多数生产环境。 2. **手动清除** 如果需立即释放空间或处理特定文件,可通过SQL命令手动清除。但操作前务必确认文件不再需要(如已备份或复制完成)。常用命令- **刷新日志并创建新binlog文件**: 使用`FLUSH LOGS`命令,这会关闭当前binlog文件并创建新文件,便于后续清理: ```sql FLUSH LOGS; ``` 此命令不会删除文件,但为删除操作做准备[^4]。 - **删除指定文件前的所有binlog文件**: 使用`PURGE BINARY LOGS TO`命令删除指定文件前的日志(例如,删除`mysql-bin.000020`前的所有文件): ```sql PURGE BINARY LOGS TO 'mysql-bin.000021'; # 删除到指定文件名前的文件 ``` 这会清除文件并更新`mysql-bin.index`索引[^3][^4]。 - **删除指定时间前的binlog文件**: 使用`PURGE BINARY LOGS BEFORE`命令删除早于特定时间点的文件: ```sql PURGE BINARY LOGS BEFORE '2023-01-01 00:00:00'; # 删除指定时间前的所有文件 ``` 该方法基于文件创建时间而非内容,确保时间格式正确[^4]。 手动清除后,建议检查磁盘空间和binlog状态: ```sql SHOW BINARY LOGS; # 确认剩余binlog文件列表 ``` #### 二、注意事项 清除binlog是高危操作,错误执行可能导致数据丢失或系统故障。关键注意事项如下: 1. **备份重要性**: 清除binlog会永久删除文件,因此在操作前必须备份所有重要日志文件(例如使用`mysqlbinlog`工具导出)。未备份的binlog一旦删除无法恢复,可能影响数据恢复能力[^1][^2]。建议定期归档binlog到外部存储。 2. **主从复制风险**: 在主从架构(如Replication)中,清除操作需格外谨慎: - 如果复制(Slave)正在运行,执行清除命令可能失败或不生效(例如Slave正在读取要删除的文件)。MySQL会返回错误提示而不执行删除[^3]。 - 如果复制已停止,删除Slave未读取的binlog文件会导致复制重新连接时失败(数据不一致)。建议在清除前检查复制状态: ```sql SHOW SLAVE STATUS; # 确认Slave是否同步 ``` 最佳实践是:仅在复制正常时操作,并确保Slave已处理完目标文件[^3]。 3. **其他风险点**: - **索引文件更新**:手动清除会清理`mysql-bin.index`索引文件。确保命令指定正确的文件名,否则可能导致索引混乱[^3]。 - **性能影响**:清除大文件可能导致I/O负载瞬间增加,建议在业务低峰期操作。 - **权限要求**:执行`PURGE`命令需要`SUPER`或`BINLOG ADMIN`权限。 4. **建议操作步骤**: - 测试环境验证清除命令- 生产环境中优先使用自动清除(设置`expire_logs_days`)。 - 手动清除时,顺序操作:先备份文件 → 执行`FLUSH LOGS` → 再`PURGE`指定文件或时间 → 验证状态[^3][^4]。 #### 三、总结 清除binlogMySQL维护的常见任务,但高优先级风险要求谨慎处理。优先使用自动清除机制(`expire_logs_days`),仅在必要时手动干预。操作前备份文件并检查主从状态,以避免灾难性后果。如果您有更多具体场景(如大型集群),建议参考MySQL官方文档或进行性能测试。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

渔夫数据库笔记

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值