三、 mysqlbinlog使用简介

本文介绍MySQL二进制日志的配置与使用方法,包括日志文件的生成、mysqlbinlog工具的应用以及如何利用日志进行数据恢复。
部署运行你感兴趣的模型镜像
     日志是把数据库的每一个变化都记载到一个专用的文件里,这种文件就叫做日志文件。二进制日志由配置文件的log-bin选项负责启用,Mysql服务器将在数据根目录创建两个新文件XXX-bin.001和xxx-bin.index,若配置选项没有给出文件名,Mysql将使用主机名称命名这两个文件,其中.index文件包含一份全体日志文件的清单。Mysql会把用户对所有数据库的内容和结构的修改情况记入XXX-bin.n文件,而 不会记录SELECT和没有实际更新的UPDATE语句
     mysqlbinlog是mysql的二进制日志工具,用于解析二进制日志文件。以下实验均在windows环境下测试。

1、打开bin-log选项,启动二进制日志功能
     有两种打开方式,一种在启动mysql服务的时候指定 --log-bin[=base_name] 选项,服务启动之后,会在[base_name]目录下生成日志文件和日志索引文件(如果有指定base_name的话,否则默认在mysql主目录下的data目录生成相应文件);另一种启动方式是修改my.ini,在[mysqld]节点下添加log-bin选项,如若无多余路径,则直接在在data目录下生成前缀为“选项名”的文件,保存后重启mysql服务。比如我在配置文件中添加:

     则重启mysql服务之后,会在data目录下生成两个文件,分别为二进制日志文件 mysqlLogBin.000001 和索引文件 mysqlLogBin.index。下面两个截图是修改my.ini并重启mysql前后log_bin的状态:

启动log-bin前

启动log-bin后
2、操作数据库
     建立数据库 -> 建表 -> 插入数据-> 修改数据-> 删除表格-> 删除数据库,具体如控制台日志所示:
mysql> show databases;
+--------------------+
| Database    |
+--------------------+
| information_schema |
| mysql    |
| performance_schema |
| test          |
+--------------------+
4 rows in set (0.00 sec)

mysql> create database jayz_test;
Query OK, 1 row affected (0.00 sec)

mysql> use jayz_test;
Database changed
mysql> show tables;
Empty set (0.00 sec)

mysql> source F:\\pet.sql;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.19 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 9 rows affected (0.05 sec)
Records: 9  Duplicates: 0  Warnings: 0

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> select * from pet;
+----------+--------+---------+------+------------+------------+
| name   | owner  | species | sex  | birth      | death      |
+----------+--------+---------+------+------------+------------+
| Fluffy   | Harold | cat     | f    | 1993-02-04 | NULL       |
| Claws    | Gwen   | cat     | m    | 1994-03-17 | NULL       |
| Buffy    | Harold | dog     | f    | 1989-05-13 | NULL       |
| Fang     | Benny  | dog     | m    | 1990-08-27 | NULL       |
| Browser  | Diane  | dog     | m    | 1979-08-31 | 1995-07-29 |
| Chripy   | Gwen   | bird    | f    | 1998-09-11 | NULL       |
| Whistler | Gwen   | bird    | NULL | 1997-12-09 | NULL       |
| Slim     | Benny  | snake   | m    | 1996-04-29 | NULL       |
| Puffball | Diane  | hamster | f    | 1999-03-30 | NULL       |
+----------+--------+---------+------+------------+------------+
9 rows in set (0.00 sec)

mysql> delete from pet where sex IS NULL;
Query OK, 1 row affected (0.03 sec)

mysql> select * from pet;
+----------+--------+---------+------+------------+------------+
| name     | owner  | species | sex  | birth      | death      |
+----------+--------+---------+------+------------+------------+
| Fluffy   | Harold | cat     | f    | 1993-02-04 | NULL       |
| Claws    | Gwen   | cat     | m    | 1994-03-17 | NULL       |
| Buffy    | Harold | dog     | f    | 1989-05-13 | NULL       |
| Fang     | Benny  | dog     | m    | 1990-08-27 | NULL       |
| Browser  | Diane  | dog     | m    | 1979-08-31 | 1995-07-29 |
| Chripy   | Gwen   | bird    | f    | 1998-09-11 | NULL       |
| Slim     | Benny  | snake   | m    | 1996-04-29 | NULL       |
| Puffball | Diane  | hamster | f    | 1999-03-30 | NULL       |
+----------+--------+---------+------+------------+------------+
8 rows in set (0.00 sec)

mysql> update pet set birth='1989-08-31' where death IS NOT NULL;
Query OK, 1 row affected (0.03 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from pet;
+----------+--------+---------+------+------------+------------+
| name     | owner  | species | sex  | birth      | death      |
+----------+--------+---------+------+------------+------------+
| Fluffy   | Harold | cat     | f    | 1993-02-04 | NULL       |
| Claws    | Gwen   | cat     | m    | 1994-03-17 | NULL       |
| Buffy    | Harold | dog     | f    | 1989-05-13 | NULL       |
| Fang     | Benny  | dog     | m    | 1990-08-27 | NULL       |
| Browser  | Diane  | dog     | m    | 1989-08-31 | 1995-07-29 |
| Chripy   | Gwen   | bird    | f    | 1998-09-11 | NULL       |
| Slim     | Benny  | snake   | m    | 1996-04-29 | NULL       |
| Puffball | Diane  | hamster | f    | 1999-03-30 | NULL       |
+----------+--------+---------+------+------------+------------+
8 rows in set (0.00 sec)

mysql> drop table pet;
Query OK, 0 rows affected (0.06 sec)

mysql> drop database jayz_test;
Query OK, 0 rows affected (0.03 sec)

mysql>

3、确定恢复内容
    在步骤2中,我们已经删除了整个jayz_test数据库及其数据,因此在恢复过程中要将drop table和drop database前的所有过程redo一遍。那么如何确定不要执行drop table及以后的sql语句呢?
    在mysqlbinlog工具中,提供了--start-position和--stop-position两个选项,前者指明从哪个位置开始重做,后者指明重做至那个位置结束,默认的,两者分别是二进制日志文件的开头和末尾。那么,上述的“位置”该如何确定? 使用mysqlbinlog命令解析二进制日志文件,并重定向保存为.txt文件,便于查看:
      mysqlbinlog F:\mysql-5.6.31-winx64\data\mysqlLogBin.000001  > F:\mysqlLogBin.txt

     可以看到,从position 2117开始,数据库开始执行drop操作,因此,我们重做至position=2117的位置就可以了。
     注意:mysqlbinlog会因为client设置字符集的缘故而运行失败,如下所示:

     而由于mysqlbinlog每次运行时是重新加载my.ini配置文件,因此使用mysqlbinlog命令时可以:1)将my.ini中[client]节点下的字符集设置注释,保存; 2)运行mysqlbinlog工具。 也即,修改后的my.ini不需要重启mysql服务也会被mysqlbinlog所识别。(记得修改回来!)

4、mysqlbinlog恢复

mysqlbinlog恢复命令
     恢复效果如下,可以看到,除了两句删除命令,其余建表,插入数据,修改数据的sql语句都被重做:


注意:
     在使用mysqlbinlog进行恢复的过程中,假如有两份二进制文件,可以通过如下做法(1)执行:
     mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p
     而不推荐以下做法(2):
     mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
     mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!
     官方给出的解释如下:
Processing binary logs this way using different connections to the server causes problems if the first log file contains a  CREATE TEMPORARY TABLE  statement and the second log contains a statement that uses the temporary table. When the first  mysql  process terminates, the server drops the temporary table. When the second mysql  process attempts to use the table, the server reports  unknown table.
     简单大意就是:做法(2)会分别建立两个mysql连接,如果第一个连接有生成临时表,这些临时表在该连接结束后被清除。而第二个连接binlog.2中有sql需要用到binglog1中的临时表结果时,此时就会执行失败,因此做法(1)更值得推荐。

参考:

您可能感兴趣的与本文相关的镜像

AutoGPT

AutoGPT

AI应用

AutoGPT于2023年3月30日由游戏公司Significant Gravitas Ltd.的创始人Toran Bruce Richards发布,AutoGPT是一个AI agent(智能体),也是开源的应用程序,结合了GPT-4和GPT-3.5技术,给定自然语言的目标,它将尝试通过将其分解成子任务,并在自动循环中使用互联网和其他工具来实现这一目标

<think> 首先,用户查询是:“我想获取mysqlbinlog使用详细说明 请问mysqlbinlog使用详细教程”。我需要基于提供的引用内容来回答,这些引用是关于MySQL Binlog的。 回顾系统级指令: - 所有行内数学表达式必须使用$...$格式,但在这个上下文中,可能没有数学表达式。 - 独立公式使用$$...$$格式,但这里可能没有。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 在引用的段落末尾自然地添加引用标识,例如[^1]。 用户可见层的要求: - 回答结构清晰,帮助用户逐步解决问题。 - 尽量保证回答真实可靠。 提供的引用: - [^1]: 介绍mysqlbinlog命令的使用格式和例子。 - [^2]: 如何使用mysqlbinlog恢复数据。 - [^3]: 如何配置MySQL开启binlog。 - [^4]: 另一个mysqlbinlog的例子。 - [^5]: 使用binlog2sql工具的教程。 用户要求的是“mysqlbinlog使用详细说明”,所以我应该聚焦在mysqlbinlog命令的具体使用上,而不是其他工具如binlog2sql。 结构化回答: 1. **介绍mysqlbinlog**:简要说明mysqlbinlog是什么。 2. **基本用法**:基于引用[^1],展示命令格式和简单例子。 3. **查看binlog文件**:解释如何以文本格式查看binlog文件,包括带条件的查看。 4. **数据恢复**:基于引用[^2],解释如何使用mysqlbinlog恢复数据。 5. **配置binlog**:可选地,基于引用[^3],简要提到如何开启binlog,因为用户可能也需要知道这个前提。 6. **其他选项或高级用法**:基于引用[^4],添加更多例子或选项。 7. **注意事项**:提到一些常见问题或建议。 添加引用标识: - 在引用具体内容时,在段落末尾添加[^n]。 生成相关问题: - 在回答结束后,添加“相关问题”部分,列出与主题相关的问题。 确保回答结构清晰: - 使用标题或段落分节。 - 用中文回答。 可能的回答大纲: 1. **mysqlbinlog简介** - mysqlbinlogMySQL提供的工具,用于解析和显示二进制日志文件的内容。 2. **命令基本格式** - 引用[^1]:mysqlbinlog [options] log_file ... 3. **查看binlog文件** - 例子:mysqlbinlog -v --base64-output=decode-rows /var/lib/mysql/master.000003 [^1] 4. **带条件查看** - 例子:使用--start-datetime, --stop-datetime, --start-position, --stop-position [^1] 5. **数据恢复** - 引用[^2]:mysqlbinlog ... | mysql -u user -p 6. **配置binlog** - 引用[^3]:如何在my.cnf中配置binlog。 7. **其他示例** - 引用[^4]:使用-r选项输出到文件。 8. **相关问题** 避免直接将引用复制粘贴,而是用自己的话总结。 最终添加相关问题: - 例如: - 1. 如何配置MySQL开启binlog日志? - 2. 如何使用mysqlbinlog恢复特定时间段的数据? - 3. mysqlbinlog常见错误及解决方法? 确保回答真实可靠:基于提供的引用,不添加外部知识。 </think> ### mysqlbinlog 使用详细教程 MySQL 的 `mysqlbinlog` 工具是用于解析和显示二进制日志(binlog)文件的命令行实用程序,它以文本格式输出 binlog 内容,便于查看或恢复数据。binlog 记录了 MySQL 数据库的所有变更操作(如插入、更新、删除),是数据恢复和复制的关键。下面我将以清晰的步骤介绍其详细使用方法,所有内容基于可靠的引用源。 #### 1. **mysqlbinlog 简介** - `mysqlbinlog` 读取 MySQL 服务器生成的二进制日志文件(通常位于 `/var/lib/mysql/` 目录),并将其转换为可读的文本格式。 - 前提条件:确保 MySQL 已开启 binlog 功能。在配置文件 `/etc/my.cnf` 中添加以下设置以启用 binlog: ``` server_id=2 log_bin=mysql-bin binlog_format=ROW expire_logs_days=30 # 日志保留天数 ``` 配置后重启 MySQL 服务生效[^3]。 - 基本命令格式:`mysqlbinlog [options] log_file ...`,其中 `log_file` 是 binlog 文件名(如 `mysql-bin.000001`)[^1]。 #### 2. **基本用法:查看 binlog 文件内容** - **以文本格式查看 binlog**:使用 `-v` 和 `--base64-output=decode-rows` 选项解码二进制数据。示例: ```bash mysqlbinlog -v --base64-output=decode-rows /var/lib/mysql/master.000003 ``` 这会显示日志中的所有事件(如 SQL 语句),适用于调试或审计[^1]。 - **输出到文件**:添加 `-r` 选项将结果保存到文件,便于后续分析。 ```bash mysqlbinlog --base64-output=decode-rows -v /var/lib/mysql/mysql-bin.000001 -r resultfile.log ``` 输出文件 `resultfile.log` 包含解码后的日志内容[^4]。 #### 3. **带条件查看 binlog** - 使用时间范围过滤:通过 `--start-datetime` 和 `--stop-datetime` 指定时间区间,只查看给定时间段内的日志。 ```bash mysqlbinlog -v --base64-output=decode-rows /var/lib/mysql/master.000003 \ --start-datetime="2023-03-01 00:00:00" \ --stop-datetime="2023-03-10 00:00:00" ``` - 使用位置范围过滤:通过 `--start-position` 和 `--stop-position` 指定日志事件的起始和结束位置(位置值从 binlog 头部获取)。 ```bash mysqlbinlog -v --base64-output=decode-rows /var/lib/mysql/master.000003 \ --start-position="5000" \ --stop-position="20000" ``` 这些选项常用于精确查找特定事务[^1]。 #### 4. **使用 mysqlbinlog 恢复数据** - **恢复命令**:将 binlog 内容通过管道导入 MySQL 服务器执行,实现数据恢复。适用于误删除或更新场景。 ```bash mysqlbinlog --no-defaults \ --start-datetime="2023-12-13 11:42:58" \ --stop-datetime="2023-12-13 11:58:40" \ /path/to/binlog/file | mysql -u username -p ``` 执行后输入 MySQL 密码,工具会重放指定时间段的日志事件以恢复数据[^2]。 - **恢复特定位置数据**:结合位置参数,避免恢复无效日志。 ```bash mysqlbinlog --start-position="1000" --stop-position="5000" /var/lib/mysql/master.000003 | mysql -u root -p ``` #### 5. **常用选项说明** - `-v` 或 `--verbose`:显示详细信息,包括解码后的行数据。 - `--base64-output=decode-rows`:强制解码 Base64 格式的行数据(binlog_format=ROW 时必需)。 - `--no-defaults`:忽略配置文件中的默认设置,避免干扰。 - `--database=db_name`:过滤指定数据库的日志(示例未显示,但支持)。 - 查看完整选项:运行 `mysqlbinlog --help` 获取帮助。 #### 6. **注意事项** - **权限要求**:运行 `mysqlbinlog` 需要读取 binlog 文件的权限(通常需 `root` 或 MySQL 用户权限)。 - **错误处理**:如果遇到解码错误,检查 binlog 格式是否为 ROW 或 MIXED(建议使用 `binlog_format=ROW`)[^3]。 - **恢复前测试**:先输出到文件查看(如上第 2 点),确认 SQL 正确后再执行恢复,避免二次破坏数据。 - **资源消耗**:解析大日志文件可能占用高内存,建议在低峰期操作。 通过以上步骤,您可以灵活使用 `mysqlbinlog` 监控数据库变更或紧急恢复数据。更多细节可参考 MySQL 官方文档。 #### 相关问题 1. 如何配置 MySQL 开启 binlog 日志功能? 2. 使用 mysqlbinlog 恢复数据时,如何避免恢复过程中的错误? 3. mysqlbinlog 工具不支持解码时,有哪些替代工具(如 binlog2sql)? 4. binlog 日志文件太大,如何自动清理和管理? [^1]: MySQL Binlog详细教程,包括命令格式和条件查询示例。 [^2]: MySQL数据恢复教程,强调时间范围恢复命令。 [^3]: MySQL Binlog配置指南,介绍开启binlog的配置文件设置。 [^4]: mysqlbinlog输出到文件的示例。 [^5]: Binlog解析工具对比,但mysqlbinlog是原生工具首选。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值