删除MYSQL BIN-LOG 日志

清理MySQL二进制日志
本文介绍如何通过MySQL命令清理占用大量磁盘空间的二进制日志,包括查看和删除具体步骤,并讨论了在有从属服务器情况下进行日志清理的方法。


想要恢愎数据库以前的资料,执行:show binlog events;
由于数据量很多,查看起来很麻烦,光打开个文件就要闪半天,所以应该适当删除部分可不用的日志。
并且如果使用的时间足够长的话,会把我的硬盘空间都给吃掉

1.登录系统,/usr/bin/mysql
使用mysql查看日志

mysql> show binary logs;

+----------------+-----------+

| Log_name       | File_size |

+----------------+-----------+

| ablelee.000001 | 150462942 |

| ablelee.000002 | 120332942 |

| ablelee.000003 | 141462942 |

+----------------+-----------+

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. 清理所有的日志,但是不包括目标日志。

<think>我们正在讨论MySQL的二进制日志Binary Log)用于数据恢复。根据引用内容,我们可以总结出以下步骤: 1. 确保MySQL已经开启了二进制日志(如果没有开启,需要修改配置文件并重启MySQL)。 2. 使用mysqlbinlog工具查看二进制日志内容,定位需要恢复的操作位置(通过时间或位置点)。 3. 使用mysqlbinlog导出特定位置或时间段的日志内容(可以输出到文件,也可以直接通过管道导入mysql执行)。 4. 执行恢复(如果导出到文件,则使用source命令或mysql命令导入;如果通过管道,则直接执行)。 具体步骤: 步骤1:检查二进制日志是否开启 - 登录MySQL,执行:`show variables like 'log_bin';`,如果Value为ON则表示开启。 步骤2:查看二进制日志文件列表 - 执行:`show binary logs;` 步骤3:查看具体的二进制日志内容,确定要恢复的位置 - 使用mysqlbinlog工具(在命令行中执行,不是在MySQL中): ```bash mysqlbinlog /var/lib/mysql/binlog.000001 ``` 如果日志文件很大,可以结合less或grep进行查找。 步骤4:根据位置点或时间点导出日志 - 按位置点导出: ```bash mysqlbinlog --start-position=107 --stop-position=2345 /var/lib/mysql/binlog.000001 > recovery.sql ``` - 按时间点导出: ```bash mysqlbinlog --start-datetime="2024-01-01 00:00:00" --stop-datetime="2024-01-02 00:00:00" /var/lib/mysql/binlog.000001 > recovery.sql ``` 步骤5:执行恢复 - 方法1:使用source命令(在MySQL命令行中): ```sql source recovery.sql; ``` - 方法2:使用mysql命令行工具: ```bash mysql -u root -p < recovery.sql ``` 注意事项: - 恢复前最好备份当前数据,以防恢复操作带来新的问题。 - 如果恢复的数据涉及多个二进制日志文件,需要按顺序导出并执行。 引用[3]和[4]提供了具体的操作示例。 另外,引用[5]提到了重做日志(Redo Log),但重做日志是InnoDB存储引擎层面的日志,用于保证事务的持久性和崩溃恢复,而二进制日志MySQL服务器层面的,主要用于复制和数据恢复。两者不同,我们这里讨论的是二进制日志。 生成相关问题: 1. 如何开启MySQL的二进制日志? 2. 二进制日志和重做日志有什么区别? 3. 如何清理旧的二进制日志文件? 请根据以上步骤和注意事项编写回答。</think>### MySQL 二进制日志Binary Log)数据恢复详解 Binary LogMySQL 的核心日志机制,记录所有修改数据库的操作(增删改)。通过解析日志可实现精确数据恢复,以下是完整操作流程: --- #### 一、前提条件 1. **开启 Binary Log** 在 MySQL 配置文件 `my.cnf` 中添加: ```ini [mysqld] log-bin = /var/log/mysql/mysql-bin.log # 日志路径 server-id = 1 # 主从复制需唯一ID binlog_format = ROW # 推荐ROW格式[^1] ``` ```bash sudo systemctl restart mysql # 重启生效 ``` 2. **验证日志状态** ```sql SHOW VARIABLES LIKE 'log_bin'; -- 需返回 ON SHOW MASTER STATUS; -- 查看当前日志文件及位置[^1] ``` --- #### 二、恢复数据核心步骤 ##### ▶ 场景1:按时间点恢复(误删数据) ```bash # 导出特定时间段的日志 mysqlbinlog \ --start-datetime="2024-06-01 09:00:00" \ --stop-datetime="2024-06-01 10:00:00" \ mysql-bin.000001 > recovery.sql # 执行恢复 mysql -u root -p < recovery.sql ``` ##### ▶ 场景2:按位置点恢复(精确操作) ```bash # 解析日志找到操作位置(如误删前的位置) mysqlbinlog mysql-bin.000001 | less # 导出指定位置区间(如 start-position=107, stop-position=2345) mysqlbinlog \ --start-position=107 \ --stop-position=2345 \ mysql-bin.000001 | mysql -u root -p[^4] ``` ##### ▶ 场景3:恢复单库/单表 ```bash # 通过库名过滤日志 mysqlbinlog \ --database=your_db_name \ mysql-bin.000001 | mysql -u root -p ``` --- #### 三、关键技巧与注意事项 1. **日志解析工具** ```bash mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 # 解码ROW格式日志 ``` - 输出内容包含实际执行的 SQL 语句[^3] 2. **安全恢复建议** - 恢复前备份当前数据:`mysqldump -u root -p --all-databases > full_backup.sql` - 测试环境验证恢复脚本 - 大事务操作分段恢复,避免锁表 3. **常见错误处理** - **日志文件不存在**:检查 `show binary logs;` 确认有效文件 - **权限问题**:确保 `mysqlbinlog` 和 MySQL 用户有日志读取权限 - **GTID 冲突**:添加 `--skip-gtids` 参数忽略 GTID 限制 --- #### 四、Binary Log 维护 1. **清理旧日志** ```sql PURGE BINARY LOGS BEFORE '2024-05-01'; -- 删除指定日期前的日志[^2] SET GLOBAL expire_logs_days = 7; -- 自动保留7天日志 ``` 2. **磁盘空间监控** ```sql SHOW BINARY LOGS; -- 查看日志文件大小 ``` --- #### 五、与 Redo Log 的区别[^5] | **特性** | **Binary Log** | **Redo Log** | |----------------|------------------------------------|----------------------------------| | 作用层级 | MySQL 服务层 | InnoDB 存储引擎层 | | 记录内容 | 逻辑操作(SQL 语句) | 物理页修改(数据页变化) | | 主要用途 | 数据恢复、主从复制 | 崩溃恢复(Crash Recovery) | | 文件位置 | 自定义路径(如 /var/log/mysql/) | 固定路径(ib_logfile0,1) | > 提示:数据恢复优先使用 Binary Log;系统崩溃恢复由 Redo Log 自动完成。 --- ### 相关问题 1. 如何基于 GTID 实现更安全的二进制日志恢复? 2. 主从复制中断时,如何利用 Binary Log 修复数据一致性? 3. Binary Log 的 ROW/STATEMENT/MIXED 格式对恢复有何影响? 4. 如何监控 Binary Log 的生成速率和磁盘占用? [^1]: Binary logMySQL 数据库的重要日志类型,它能够记录对数据库进行的所有修改操作[^1]。 [^2]: 删除旧的 Binary Log 文件可释放磁盘空间或维护数据库[^2]。 [^3]: 通过 `mysqlbinlog` 解析日志并定位操作位置[^3]。 [^4]: 基于位置点恢复不限定于某个特定的库或表[^4]。 [^5]: Redo Log 用于在 MySQL 崩溃恢复期间纠正由不完整事务写入的数据[^5]。
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值