mysqlbinlog恢复数据实战+myflash恢复数据
mysqlbinlog binlog.000005 -vv >/tmp/test.binlog
#./flashback --databaseNames="test" --tableNames="t1" --sqlTypes="delete" --start-position=711 --stop-position=877 --binlogFileNames=/var/lib/mysql/mysql-bin.000005 --outBinlogFileNameBase=/tmp/retest-bin.log
./flashback --databaseNames="test" --tableNames="t1" --sqlTypes="delete" --start-position=854 --binlogFileNames=/var/lib/mysql/mysql-bin.000005 --outBinlogFileNameBase=/tmp/retest-bin.log
产生这个retest-binlog文件
使用这个文件恢复数据
查看数据，可以看出已经恢复
mysqldump全量备份
binlog日志 可以做增量备份，从一个点到另一个点做备份
create table t1(id decimal,value varchar(10));
Query OK, 0 rows affected (0.33 sec)
insert into t1 values(1,'a'),(2,'b'),(3,'c');
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysqldump -uroot -pNari.1234 --source-data=2 --single-transaction -A >/root/all.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.
[root@clone1 mysql]# du -sh /root/all.sql
1.3M /root/all.sql
怎么恢复数据？
先恢复刚才的备份数据
定位做备份时候的binlog位置
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=1174;
mysqlbinlog binlog.000001 -vv >/root/test.binlog 以明文展示非乱码，使用-vv参数
1484
定位备份到truncate中间的点在什么地方，然后恢复
mysqlbinlog /var/lib/mysql/binlog.000001 --start-position=1174 --stop-position=1484 -vv > /root/restore.binlog
从上面可以看出数据已经恢复！！！！！！！！！！！
####################################################################################################################
binlog 我们中文一般称作归档日志，如果大家看过松哥之前发的 MySQL 主从搭建，应该对这个日志有印象，当我们搭建 MySQL 主从的时候就离不开 binlog（传送门：MySQL8 主从复制踩坑指南）。
binlog 是 MySQL Server 层的日志，而不是存储引擎自带的日志，它记录了所有的 DDL 和 DML(不包含数据查询语句)语句，而且是以事件形式记录，还包含语句所执行的消耗的时间等，需要注意的是：
-
binlog 是一种逻辑日志，他里边所记录的是一条 SQL 语句的原始逻辑，例如给某一个字段 +1，注意这个区别于 redo log 的物理日志（在某个数据页上做了什么修改）。
-
binlog 文件写满后，会自动切换到下一个日志文件继续写，而不会覆盖以前的日志，这个也区别于 redo log，redo log 是循环写入的，即后面写入的可能会覆盖前面写入的。
-
一般来说，我们在配置 binlog 的时候，可以指定 binlog 文件的有效期，这样在到期后，日志文件会自动删除，这样避免占用较多存储空间。
根据 MySQL 官方文档的介绍，开启 binlog 之后，大概会有 1% 的性能损耗，不过这还是可以接受的，一般来说，binlog 有两个重要的使用场景：
1.主从复制
2.使用binlog恢复删除数据
mysqlbinlog --start-datetime="2023-03-09 15:07:43" --stop-datetime="2023-03-09 15:12:38" --database=test /var/lib/mysql/mysql-bin.000002 | mysql -uroot -pNari.1234 -v test
Mysql 通过binlog日志恢复数据
Binlog日志，即binary log，是二进制日志文件，有两个作用，一个是增量备份，另一个是主从复制，即主节点维护一个binlog日志文件，从节点从binlog中同步数据，也可以通过binlog日志来恢复数据
1，登录mysql查看binlog日志的状态，输入show variables like ‘%log_bin%’;查看binlog为off关闭状态
2，开启mysql binlog日志，进入mysql配置文件(vi /etc/my.cnf) 在mysqld区域内添加如下内容，①server-id = 1(单个节点id) ②log-bin= /var/lib/mysql/mysql-bin(位置一般和mysql库文件所在位置一样) ③expire_logs_days = 10(表示此日志保存时间为10天),重启mysqld,再次查看binlog日志开启状态为ON
3，Binlog日志包括两类文件；第一个是二进制索引文件(后缀名为.index),第二个为日志文件(后缀名为.00000*),记录数据库所有的DDL和DML(除了查询语句select)语句事件
4，查看所有binlog日志文件列表:show master logs;
5，查看最后一个binlog日志的编号名称及其最后一个操作事件pos结束点的值：show master status;
6，Flush logs 刷新日志，此刻开始产生一个新编号的binlog文件，例如：
每当mysqld服务重启时，会自动执行刷新binlog日志命令，mysqldump备份数据时加-F选项也会刷新binlog日志
7，清空所有binlog日志命令:reset master;
8，查看binlog文件内容，使用查看工具mysqlbinlog来查看(cat/vi/more都是无法打开的)
9，上面的方法读取内容较多不易观察，以下命令更为方便查看命令：show binlog events in ‘mysql-bin.000003’;
10，指定查询,从pos点406开始查询，如下：
11，指定查询，从pos点154开始查询，中间跳过2行，查询4条数据，如图：
12，利用binlog日志恢复mysql数据，例如，现有一张数据表如图：此表位于hello数据库
现在将此数据库备份到本地(模拟每周的备份情况)，备份命令如下
可以在数据备份之前或者之后执行flush logs重新生成一个binlog日志用来记录备份之后的所有增删改操作(重新生成日志更好找pos点)，由于业务需求，现在对表进行插入
数据，修改数据，如图新增了两条数据id 为5和6，修改后数据如图，
6的年龄修改成了30
13，由于操作失误，误删除了数据库，所有数据都不见了,此时可以通过binlog日志恢复数据，由于之前有做了数据库备份，所以可以先将备份的数据导入进去，剩下缺少的就是备份之后操作所产生的内容(备份之后执行了插入内容以及更改内容)，先恢复备份的数据：创建库hello并选择库(use hello)，通过命令source /root/hello.sql将数据库内容导入，然后执行
14，恢复的内容如下所示：
15，上面恢复的数据只是截止到备份时间的数据，剩下缺少的数据可以通过binlog日志来恢复，由于我们备份数据库之前重新创建了mysql-bin.000006日志，所以备份后的所有操作都保存在这个日志中，可以先备份下这个日志文件，cp mysql-bin.000006 /root/ 接着执行flush logs 刷新日志，重新创建了一个binlog日志7
16，重新创建一个日志7的目的：接下来所有操作的数据都会写入到日志7中，日志6中不会在写入任何数据(方便根据日志6的内容恢复数据，因为日志6的数据就是备份之后到删库之前的所有操作日志，重建日志7不会有过多的数据影响恢复)
17，登录mysql 查看日志6: show binlog events in ‘mysql-bin.000006’;结果如下：
查看日志发现，在备份数据后首先执行的是插入数据操作(在一个事务内)，此时可以通过指定pos结束点恢复(部分恢复)，如图，pos结束点位435(事务已提交表示结束)，执行命令如下, /usr/bin/mysqlbinlog --stop-position=435 --database=hello /var/lib/mysql/mysql-bin.000006 | /usr/bin/mysql -uroot -p密码 -v hello (其中整个命令的含义是通过mysqlbinlog读取日志内容并通过管道传给mysql命令，-v表示执行此mysql命令)执行后查询表发现如下：
备份之后插入的数据都出现了，目前还差一次修改的数据没有找回来，接着看日志6如图，
发现执行更新操作的事务区间为573到718，所以可以执行以下命令来恢复这段数据，/usr/bin/mysqlbinlog --start-position=573 --stop-position=718 --database=hello /var/lib/mysql/mysql-bin.000006 | /usr/bin/mysql -uroot -p密码 -v hello注意其中的符号都是英文状态下(只恢复这段事务区间的数据也就是更新的数据)，恢复结果如下：
更改的数据回来了，也可以最开始的时候直接通过最终的pos结束点718来恢复
18，还有一种通过时间来恢复，还是先备份当前数据库(备份之前先flush logs创建一个新的binlog日志文件9)，然后修改数据插入数据后如图，
修改后将当前数据库删除，(删除库之后再执行一下flush logs创建一个新的日志文件，这样新的操作都写入到这个文件中，上个日志文件只用来恢复数据，不会有其余数据混入)现在我们通过时间点来恢复从备份数据后到删除数据库这期间所有操作的数据，首先通过mysqlbinlog来了查看日志文件9如图所示，
19，执行命令：/usr/bin/mysqlbinlog --start-datetime="2018-04-27 20:57:55" --stop-datetime="2018-04-27 20:58:18" --database=hello /var/lib/mysql/mysql-bin.000009 | /usr/bin/mysql -uroot -p8856769abcd -v hello 更改的数据得到了恢复
20，插入数据的日志时间如图：
执行命令/usr/bin/mysqlbinlog --start-datetime="2018-04-27 20:58:18" --stop-datetime="2018-04-27 20:58:35" --database=hello /var/lib/mysql/mysql-bin.000009 | /usr/bin/mysql -uroot -p8856769abcd -v hello 插入的数据得到了恢复，如图，
#################################################################################
MySQL 5.7 - 通过 BINLOG 恢复数据
日常开发，运维中，经常会出现误删数据的情况。误删数据的类型大致可分为以下几类：
- 使用 delete 误删行
- 使用 drop table 或 truncate table 误删表
- 使用 drop database 语句误删数据库
- 使用 rm 命令误删整个 MySQL 实例。
不同的情况，都会有其优先的解决方案：
- 针对误删行，可以通过 Flashback 工具将数据恢复
- 针对误删表或库，一般采用通过 BINLOG 将数据恢复。
- 而对于误删 MySQL 实例，则需要我们搭建 HA 的 MySQL 集群，并保证我们的数据跨机房，跨城市保存。
本篇主要讨论的内容是误删表或者库，会先介绍有关 BINLOG 的操作命令，然后会对误删表的这种情况进行实际的模拟。
BINLOG 常见操作命令#
BINLOG 的查询方式一般分为两种，一种是进入 MySQL 控制台进行查询，另一种是通过 MySQL 提供的工具 mysqlbinlog 进行查询，两者的不同会在下面介绍。
通过 MySQL Cli 查询 BINLOG 信息#
在 cli 中，常见的命令如下：
# 查询 BINLOG 格式
show VARIABLES like 'binlog_format';
# 查询 BINLOG 位置
show VARIABLES like 'datadir';
# 查询当前数据库中 BINLOG 名称及大小
show binary logs;
# 查看 master 正在写入的 BINLOG 信息
show master status\G;
# 通过 offset 查看 BINLOG 信息
show BINLOG events in 'mysql-bin.000034' limit 9000, 10;
# 通过 position 查看 binlog 信息
show BINLOG events in 'mysql-bin.000034' from 1742635 limit 10;
使用 show BINLOG events 的问题：
- 使用该命令时，如果当前 binlog 文件很大，而且没有指定
limit，会引发对资源的过度消耗。因为 MySQL 客户端需要将 binlog 的全部内容处理，返回并显示出来。为了防止这种情况，mysqlbinlog 工具是一个很好的选择。
通过 mysqlbinlog 查询 BINLOG 信息#
在介绍 mysqlbinlog 工具使用前，先来看下 BINLOG 文件的内容：
# 查询 BINLOG 的信息
mysqlbinlog --no-defaults mysql-bin.000034 | less
# at 141
#100309 9:28:36 server id 123 end_log_pos 245
Query thread_id=3350 exec_time=11 error_code=0
at表示 offset 或者说事件开始的起始位置100309 9:28:36 server id 123表示 server 123 开始执行事件的日期end_log_pos 245表示事件的结束位置 + 1，或者说是下一个事件的起始位置。exec_time表示在 master 上花费的时间，在 salve 上，记录的时间是从 Master 记录开始，一直到 Slave 结束完成所花费的时间。rror_code=0表示没有错误发生。
在大致了解 binlog 的内容后，mysqlbinlog 的用途有哪些？：
- mysqlbinlog 可以作为代替 cli 读取 binlog 的工具。
- mysqlbinlog 可以将执行过的 SQL 语句输出，用于数据的恢复或备份。
查询 BINLOG 日志：
# 查询规定时候后发生的 BINLOG 日志
mysqlbinlog --no-defaults --base64-output=decode-rows -v \
--start-datetime "2019-11-22 14:00:00" \
--database sync_test mysql-bin.000034 | less
导出 BINLOG 日志，用于分析和排查 sql 语句：
mysqlbinlog --no-defaults --base64-output=decode-rows -v \
--start-datetime "2019-11-22 14:00:00" \
--database sync_test \
mysql-bin.000034 > /home/mysql_backup/binlog_raw.sql
导入 BINLOG 日志
# 通过 BINLOG 进行恢复。
mysqlbinlog --start-position=1038 --stop-position=1164 \
--database=db_name mysql-bin.000034 | \
mysql -u cisco -p db_name
# 通过 BINLOG 导出的 sql 进行恢复。
mysql -u cisco -p db_name < binlog_raw.sql
mysqlbinlog 的常用参数：
--database仅仅列出配置的数据库信息--no-defaults读取没有选项的文件, 指定的原因是由于 mysqlbinlog 无法识别 BINLOG 中的default-character-set=utf8指令--offset跳过 log 中 N 个条目--verbose将日志信息重建为原始的 SQL 陈述。-v仅仅解释行信息-vv不但解释行信息，还将 SQL 列类型的注释信息也解析出来
--start-datetime显示从指定的时间或之后的时间的事件。- 接收
DATETIME或者TIMESTRAMP格式。
- 接收
--base64-output=decode-rows将 BINLOG 语句中事件以 base-64 的编码显示，对一些二进制的内容进行屏蔽。AUTO默认参数，自动显示 BINLOG 中的必要的语句NEVER不会显示任何的 BINLOG 语句，如果遇到必须显示的 BINLOG 语言，则会报错退出。DECODE-ROWS显示通过-v显示出来的 SQL 信息，过滤到一些 BINLOG 二进制数据。
MySQL Cli 和 mysqlbinlog 工具之间的比较#
如果想知道当前 MySQL 中正在写入的 BINLOG 的名称，大小等基本信息时，可以通过 Cli 相关的命令来查询。
但想查询，定位，恢复 BINLOG 中具体的数据时，要通过 mysqlbinlog 工具，因为相较于 Cli 来说，mysqlbinlog 提供了 --start-datetime，--stop-position 等这样更为丰富的参数供我们选择。这时 Cli 中 SHOW BINLOG EVENTS 的简要语法就变得相形见绌了。
使用 BINLOG 恢复数据#
恢复的大致流程如下：
- 会创建数据库和表，并插入数据。
- 误删一条数据。
- 继续插入数据。
- 误删表。
- 最后将原来以及之后插入的数据进行恢复。
准备数据#
准备数据库，表及数据：
# 创建临时数据库
CREATE DATABASE IF NOT EXISTS test_binlog \
default charset utf8 COLLATE utf8_general_ci;
# 创建临时表
CREATE TABLE `sync_test` (`id` int(11) \
NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, \
PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
# 添加数据
insert into sync_test (id, name) values (null, 'xiaoa');
insert into sync_test (id, name) values (null, 'xiaob');
insert into sync_test (id, name) values (null, 'xiaoc');
# 查看添加的数据
select * from sync_test;
删除表或者数据#
误删操作：
# 删除 name=xiaob 的数据
delete from sync_test where id=3
# 插入几条数据
insert into sync_test (id, name) values (null, 'xiaod');
insert into sync_test (id, name) values (null, 'xiaoe');
insert into sync_test (id, name) values (null, 'xiaof');
# 删除表
DROP TABLE sync_test;
数据的恢复#
在执行数据恢复前，如果操作的是生产环境，会有如下的建议：
-
使用
flush logs命令，替换当前主库中正在使用的 binlog 文件，好处如下：- 可将误删操作，定位在一个 BINLOG 文件中，便于之后的数据分析和恢复。
- 避免操作正在被使用的 BINLOG 文件，防止发生意外情况。
-
数据的恢复不要在生产库中执行，先在临时库恢复，确认无误后，再倒回生产库。防止对数据的二次伤害。
通常来说，恢复主要有两个步骤：
- 在临时库中，恢复定期执行的全量备份数据。
- 然后基于全量备份的数据点，通过 BINLOG 来恢复误操作和正常的数据。
使用 BINLOG 做数据恢复前：
# 查看正在使用的 Binlog 文件
show master status\G;
# 显示结果是： mysql-bin.000034
# 执行 flush logs 操作，生成新的 BINLOG
flush logs;
# 查看正在使用的 Binlog 文件
show master status\G;
# 结果是：mysql-bin.000035
确定恢复数据的步骤：
这里主要是有两条误删的操作，数据行的误删和表的误删。有两种方式进行恢复。
- 方式一：首先恢复到删除表操作之前的位置，然后再单独恢复误删的数据行。
- 方式二：首先恢复到误删数据行的之前的位置，然后跳过误删事件再恢复数据表操作之前的位置。
这里采用方式一的方案进行演示，由于是演示，就不额外找一个临时库进行全量恢复了，直接进行操作。
查询创建表的事件位置和删除表的事件位置
# 根据时间确定位置信息
mysqlbinlog --no-defaults --base64-output=decode-rows -v \
--start-datetime "2019-11-22 14:00:00" \
--database test_binlog mysql-bin.000034 | less
创建表的开始位置：
删除表的结束位置：
插入 name='xiaob' 的位置：
# 根据位置导出 SQL 文件
mysqlbinlog --no-defaults --base64-output=decode-rows -v \
--start-position "2508132" --stop-position "2511004" \
--database test_binlog mysql-bin.000034 \
> /home/mysql_backup/test_binlog_step1.sql
mysqlbinlog --no-defaults --base64-output=decode-rows -v \
--start-position "2508813" --stop-position "2509187" \
--database test_binlog mysql-bin.000034 \
> /home/mysql_backup/test_binlog_step2.sql
# 使用 mysql 进行恢复
mysql -u cisco -p < /home/mysql_backup/test_binlog_step1.sql
mysql -u cisco -p < /home/mysql_backup/test_binlog_step2.sql
MySQL 5.7 中无论是否打开 GTID 的配置，在每次事务开启时，都首先会出 GTID 的一个事务，用于并行复制。所以在确定导出开始事务位置时，要算上这个事件。
在使用 --stop-position 导出时，会导出在指定位置的前一个事件，所以这里要推后一个事务。
对于 DML 的语句，主要结束位置要算上 COMMIT 的位置。
总结#
在文章开始时，我们熟悉了操作 BINLOG 的两种方式 CLI 和 mysqlbinlog 工具，接着介绍了其间的区别和使用场景，对于一些大型的 BINLOG 文件，使用 mysqlbinlog 会更加的方便和效率。并对 mysqlbinlog 的一些常见参数进行了介绍。
接着通过使用 mysqlbinlog 实际模拟了数据恢复的过程，并在恢复数据时，提出了一些需要注意的事项，比如 flush logs 等。
最后在恢复数据时，要注意 start-position 和 end-position 的一些小细节，来保证找到合适的位置。
参考#
mysql数据库中，flush logs语句的作用是什么呢？
需求描述：
今天在研究mysql数据库的备份和恢复，用到了flush logs这个SQL语句。
所以，在此进行测试，并且记录该SQL语句的作用。
概念描述：
在mysql数据库，如果数据库启动的时候，启用了log-bin选项，那么，
所有对于数据库的修改都会记录在binary log中，binary log可以用于数据库的恢复（基于时间点的恢复）
操作过程：
1.查看my.cnf中配置的log-bin参数
[mysql@redhat6 ~]$ grep "log-bin" /etc/my.cnf log-bin=/mysql/data/mysql-bin/mysql-bin #定义binary log所在的目录及bin log以什么名字开始。 #log-bin=mysql-bin
2.在mysql数据库中，查看log_bin系统变量的设置
mysql> show variables like 'log_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ 1 row in set (0.00 sec)
备注：以上的设置，表示数据库已经开启了binary log.
3.查看binary log在操作系统上生成的文件
[mysql@redhat6 ~]$ cd /mysql/data/mysql-bin/ [mysql@redhat6 mysql-bin]$ ls -l total 969552 -rw-rw----. 1 mysql mysql 27693 Jan 18 17:15 mysql-bin.000001 -rw-rw----. 1 mysql mysql 1133097 Jan 18 17:15 mysql-bin.000002 -rw-rw----. 1 mysql mysql 264 Jan 18 17:20 mysql-bin.000003 -rw-rw----. 1 mysql mysql 26636 Jan 18 17:24 mysql-bin.000004 -rw-rw----. 1 mysql mysql 1133097 Jan 18 17:24 mysql-bin.000005 -rw-rw----. 1 mysql mysql 126 Jan 18 17:34 mysql-bin.000006 -rw-rw----. 1 mysql mysql 126 Jan 18 17:36 mysql-bin.000007 -rw-rw----. 1 mysql mysql 126 Jan 18 17:38 mysql-bin.000008 -rw-rw----. 1 mysql mysql 126 Jan 18 17:40 mysql-bin.000009 -rw-rw----. 1 mysql mysql 126 Jan 19 09:59 mysql-bin.000010 -rw-rw----. 1 mysql mysql 126 Jan 19 10:03 mysql-bin.000011 -rw-rw----. 1 mysql mysql 126 Jan 19 10:05 mysql-bin.000012 -rw-rw----. 1 mysql mysql 126 Jan 19 10:06 mysql-bin.000013 -rw-rw----. 1 mysql mysql 8428 Jan 19 17:57 mysql-bin.000014 -rw-rw----. 1 mysql mysql 172320573 Jan 19 18:00 mysql-bin.000015 -rw-rw----. 1 mysql mysql 126 Jan 22 18:07 mysql-bin.000016 -rw-rw---- 1 mysql mysql 1202 Jan 23 18:21 mysql-bin.000017 -rw-rw---- 1 mysql mysql 231 Jan 23 22:44 mysql-bin.000018 -rw-rw---- 1 mysql mysql 486 Jan 24 18:13 mysql-bin.000019 -rw-rw---- 1 mysql mysql 126 Jan 25 11:40 mysql-bin.000020 -rw-rw---- 1 mysql mysql 126 Jan 25 14:05 mysql-bin.000021 -rw-rw---- 1 mysql mysql 126 Jan 25 14:10 mysql-bin.000022 -rw-rw---- 1 mysql mysql 126 Jan 25 18:02 mysql-bin.000023 -rw-rw---- 1 mysql mysql 126 Jan 26 21:21 mysql-bin.000024 -rw-rw---- 1 mysql mysql 126 Jan 29 14:20 mysql-bin.000025 -rw-rw---- 1 mysql mysql 3779 Jan 29 14:41 mysql-bin.000026 -rw-rw---- 1 mysql mysql 126 Jan 29 15:29 mysql-bin.000027 -rw-rw---- 1 mysql mysql 520 Jan 29 16:12 mysql-bin.000028 -rw-rw---- 1 mysql mysql 126 Jan 29 17:59 mysql-bin.000029 -rw-rw---- 1 mysql mysql 2261 Jan 30 17:32 mysql-bin.000030 -rw-rw---- 1 mysql mysql 2161843 Jan 31 12:58 mysql-bin.000031 -rw-rw---- 1 mysql mysql 2243815 Jan 31 18:43 mysql-bin.000032 -rw-rw---- 1 mysql mysql 165265 Feb 1 17:37 mysql-bin.000033 -rw-rw---- 1 mysql mysql 12792 Feb 2 19:25 mysql-bin.000034 -rw-rw---- 1 mysql mysql 264 Feb 5 11:22 mysql-bin.000035 -rw-rw---- 1 mysql mysql 744 Feb 5 17:04 mysql-bin.000036 -rw-rw---- 1 mysql mysql 1769 Feb 5 19:07 mysql-bin.000037 -rw-rw---- 1 mysql mysql 5600 Feb 26 17:31 mysql-bin.000038 -rw-rw---- 1 mysql mysql 126 Feb 27 10:13 mysql-bin.000039 -rw-rw---- 1 mysql mysql 150 Feb 27 10:14 mysql-bin.000040 -rw-rw---- 1 mysql mysql 126 Feb 27 10:14 mysql-bin.000041 -rw-rw---- 1 mysql mysql 126 Feb 27 10:30 mysql-bin.000042 -rw-rw---- 1 mysql mysql 126 Feb 27 10:32 mysql-bin.000043 -rw-rw---- 1 mysql mysql 126 Feb 27 10:51 mysql-bin.000044 -rw-rw---- 1 mysql mysql 126 Feb 27 10:53 mysql-bin.000045 -rw-rw---- 1 mysql mysql 126 Feb 27 11:04 mysql-bin.000046 -rw-rw---- 1 mysql mysql 126 Feb 27 12:41 mysql-bin.000047 -rw-rw---- 1 mysql mysql 626 Feb 27 14:34 mysql-bin.000048 -rw-rw---- 1 mysql mysql 715342328 Feb 27 15:54 mysql-bin.000049 -rw-rw---- 1 mysql mysql 308 Feb 27 16:03 mysql-bin.000050 -rw-rw---- 1 mysql mysql 305 Feb 27 16:27 mysql-bin.000051 -rw-rw---- 1 mysql mysql 126 Feb 27 16:28 mysql-bin.000052 -rw-rw---- 1 mysql mysql 126 Feb 27 18:17 mysql-bin.000053 -rw-rw---- 1 mysql mysql 126 Feb 28 18:33 mysql-bin.000054 -rw-rw---- 1 mysql mysql 126 Feb 28 18:40 mysql-bin.000055 -rw-rw---- 1 mysql mysql 126 Mar 1 15:04 mysql-bin.000056 -rw-rw---- 1 mysql mysql 126 Mar 1 17:45 mysql-bin.000057 -rw-rw---- 1 mysql mysql 6611 Mar 2 17:04 mysql-bin.000058 -rw-rw---- 1 mysql mysql 16241 Mar 5 10:47 mysql-bin.000059 -rw-rw---- 1 mysql mysql 126 Mar 6 17:48 mysql-bin.000060 -rw-rw---- 1 mysql mysql 1111 Mar 8 18:40 mysql-bin.000061 -rw-rw---- 1 mysql mysql 126 Mar 9 10:06 mysql-bin.000062 -rw-rw---- 1 mysql mysql 107 Mar 9 10:12 mysql-bin.000063 -rw-rw---- 1 mysql mysql 42103 Mar 9 18:27 mysql-bin.000064 -rw-rw---- 1 mysql mysql 7690 Mar 12 23:28 mysql-bin.000065 -rw-rw---- 1 mysql mysql 107 Mar 15 16:48 mysql-bin.000066 -rw-rw---- 1 mysql mysql 126 Mar 19 18:04 mysql-bin.000067 -rw-rw---- 1 mysql mysql 126 Mar 20 09:49 mysql-bin.000068 -rw-rw---- 1 mysql mysql 126 Mar 20 09:53 mysql-bin.000069 -rw-rw---- 1 mysql mysql 264 Mar 20 10:05 mysql-bin.000070 -rw-rw---- 1 mysql mysql 264 Mar 20 10:50 mysql-bin.000071 -rw-rw---- 1 mysql mysql 126 Mar 20 10:51 mysql-bin.000072 -rw-rw---- 1 mysql mysql 126 Mar 20 10:55 mysql-bin.000073 -rw-rw---- 1 mysql mysql 264 Mar 20 10:57 mysql-bin.000074 -rw-rw---- 1 mysql mysql 107 Mar 20 10:57 mysql-bin.000075 -rw-rw---- 1 mysql mysql 52702236 Mar 21 15:01 mysql-bin.000076 -rw-rw---- 1 mysql mysql 107 Mar 26 14:40 mysql-bin.000077 -rw-rw---- 1 mysql mysql 23077422 Mar 28 18:13 mysql-bin.000078 -rw-rw---- 1 mysql mysql 22032005 Mar 29 15:26 mysql-bin.000079 -rw-rw---- 1 mysql mysql 107 Mar 30 14:06 mysql-bin.000080 -rw-rw---- 1 mysql mysql 107 Apr 2 09:21 mysql-bin.000081 -rw-rw---- 1 mysql mysql 150 Apr 3 15:58 mysql-bin.000082 -rw-rw---- 1 mysql mysql 150 Apr 3 16:00 mysql-bin.000083 -rw-rw---- 1 mysql mysql 150 Apr 3 16:46 mysql-bin.000084 -rw-rw---- 1 mysql mysql 150 Apr 3 16:47 mysql-bin.000085 -rw-rw---- 1 mysql mysql 150 Apr 3 16:52 mysql-bin.000086 -rw-rw---- 1 mysql mysql 238 Apr 3 17:12 mysql-bin.000087 -rw-rw---- 1 mysql mysql 150 Apr 3 17:14 mysql-bin.000088 -rw-rw---- 1 mysql mysql 107 Apr 3 17:14 mysql-bin.000089 -rw-rw----. 1 mysql mysql 2611 Apr 3 17:14 mysql-bin.index
备注：binary log是以mysql-bin开头的，然后点后面是binary log的序号。
4.mysql-bin.index文件是所有bin log文件的列表（列出所有binary log所在路径和名字，./表示的是data目录）
[mysql@redhat6 mysql-bin]$ cat mysql-bin.index ./mysql-bin.000001 ./mysql-bin.000002 ./mysql-bin.000003 ./mysql-bin.000004 ./mysql-bin.000005 ./mysql-bin.000006 ./mysql-bin.000007 ./mysql-bin.000008 ./mysql-bin.000009 ./mysql-bin.000010 ./mysql-bin.000011 ./mysql-bin.000012 ./mysql-bin.000013 ./mysql-bin.000014 ./mysql-bin.000015 ./mysql-bin.000016 ./mysql-bin.000017 ./mysql-bin.000018 ./mysql-bin.000019 ./mysql-bin.000020 ./mysql-bin.000021 ./mysql-bin.000022 ./mysql-bin.000023 ./mysql-bin.000024 ./mysql-bin.000025 ./mysql-bin.000026 ./mysql-bin.000027 ./mysql-bin.000028 ./mysql-bin.000029 ./mysql-bin.000030 ./mysql-bin.000031 ./mysql-bin.000032 ./mysql-bin.000033 ./mysql-bin.000034 ./mysql-bin.000035 ./mysql-bin.000036 ./mysql-bin.000037 ./mysql-bin.000038 ./mysql-bin.000039 ./mysql-bin.000040 ./mysql-bin.000041 ./mysql-bin.000042 ./mysql-bin.000043 /mysql/data/mysql-bin/mysql-bin.000044 /mysql/data/mysql-bin/mysql-bin.000045 /mysql/data/mysql-bin/mysql-bin.000046 /mysql/data/mysql-bin/mysql-bin.000047 /mysql/data/mysql-bin/mysql-bin.000048 /mysql/data/mysql-bin/mysql-bin.000049 /mysql/data/mysql-bin/mysql-bin.000050 /mysql/data/mysql-bin/mysql-bin.000051 /mysql/data/mysql-bin/mysql-bin.000052 /mysql/data/mysql-bin/mysql-bin.000053 /mysql/data/mysql-bin/mysql-bin.000054 /mysql/data/mysql-bin/mysql-bin.000055 /mysql/data/mysql-bin/mysql-bin.000056 /mysql/data/mysql-bin/mysql-bin.000057 /mysql/data/mysql-bin/mysql-bin.000058 /mysql/data/mysql-bin/mysql-bin.000059 /mysql/data/mysql-bin/mysql-bin.000060 /mysql/data/mysql-bin/mysql-bin.000061 /mysql/data/mysql-bin/mysql-bin.000062 /mysql/data/mysql-bin/mysql-bin.000063 /mysql/data/mysql-bin/mysql-bin.000064 /mysql/data/mysql-bin/mysql-bin.000065 /mysql/data/mysql-bin/mysql-bin.000066 /mysql/data/mysql-bin/mysql-bin.000067 /mysql/data/mysql-bin/mysql-bin.000068 /mysql/data/mysql-bin/mysql-bin.000069 /mysql/data/mysql-bin/mysql-bin.000070 /mysql/data/mysql-bin/mysql-bin.000071 /mysql/data/mysql-bin/mysql-bin.000072 /mysql/data/mysql-bin/mysql-bin.000073 /mysql/data/mysql-bin/mysql-bin.000074 /mysql/data/mysql-bin/mysql-bin.000075 /mysql/data/mysql-bin/mysql-bin.000076 /mysql/data/mysql-bin/mysql-bin.000077 /mysql/data/mysql-bin/mysql-bin.000078 /mysql/data/mysql-bin/mysql-bin.000079 /mysql/data/mysql-bin/mysql-bin.000080 /mysql/data/mysql-bin/mysql-bin.000081 /mysql/data/mysql-bin/mysql-bin.000082 /mysql/data/mysql-bin/mysql-bin.000083 /mysql/data/mysql-bin/mysql-bin.000084 /mysql/data/mysql-bin/mysql-bin.000085 /mysql/data/mysql-bin/mysql-bin.000086 /mysql/data/mysql-bin/mysql-bin.000087 /mysql/data/mysql-bin/mysql-bin.000088 /mysql/data/mysql-bin/mysql-bin.000089
5.查看当前数据库binary log的位置
mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000089 | 107 | | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
备注：当前使用的bin log是“mysql-bin.000089”，位置是107.
6.执行flush logs命令
mysql> flush logs; Query OK, 0 rows affected (0.04 sec) mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000090 | 107 | | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
备注：通过执行flush logs命令之后，再次查询binary log信息，发现已经使用了一个新的bin log文件了。
7.查看操作系统上是否也多了一个binary log文件
-rw-rw---- 1 mysql mysql 22032005 Mar 29 15:26 mysql-bin.000079 -rw-rw---- 1 mysql mysql 107 Mar 30 14:06 mysql-bin.000080 -rw-rw---- 1 mysql mysql 107 Apr 2 09:21 mysql-bin.000081 -rw-rw---- 1 mysql mysql 150 Apr 3 15:58 mysql-bin.000082 -rw-rw---- 1 mysql mysql 150 Apr 3 16:00 mysql-bin.000083 -rw-rw---- 1 mysql mysql 150 Apr 3 16:46 mysql-bin.000084 -rw-rw---- 1 mysql mysql 150 Apr 3 16:47 mysql-bin.000085 -rw-rw---- 1 mysql mysql 150 Apr 3 16:52 mysql-bin.000086 -rw-rw---- 1 mysql mysql 238 Apr 3 17:12 mysql-bin.000087 -rw-rw---- 1 mysql mysql 150 Apr 3 17:14 mysql-bin.000088 -rw-rw---- 1 mysql mysql 150 Apr 3 17:35 mysql-bin.000089 -rw-rw---- 1 mysql mysql 107 Apr 3 17:35 mysql-bin.000090 #操作系统上生成了新的binary log文件。 -rw-rw----. 1 mysql mysql 2650 Apr 3 17:35 mysql-bin.index
小结：
flush logs命令的作用就是关闭当前使用的binary log，然后打开一个新的binary log文件，文件的序号加1.
mysqlbinlog binlog.000005 -vv >/tmp/test.binlog
#./flashback --databaseNames="test" --tableNames="t1" --sqlTypes="delete" --start-position=711 --stop-position=877 --binlogFileNames=/var/lib/mysql/mysql-bin.000005 --outBinlogFileNameBase=/tmp/retest-bin.log
./flashback --databaseNames="test" --tableNames="t1" --sqlTypes="delete" --start-position=854 --binlogFileNames=/var/lib/mysql/mysql-bin.000005 --outBinlogFileNameBase=/tmp/retest-bin.log
产生这个retest-binlog文件
使用这个文件恢复数据
查看数据，可以看出已经恢复
退出 订阅评论 我的博客
[Ctrl+Enter快捷键提交]
· 我又和 redis 超时杠上了
· 巧用 CSS 变量，制作高级感拉满的网格动画
· 记录一次锁的优化
· RabbitMQ 真实生产故障问题还原与分析
· .netcore 全局异常处理
· new bing功能使用
· 我的十年编程路 2018篇
· 我又和redis超时杠上了
· ASP.NET Core中如何限制响应发送速率（不是调用频率）
· 常用的Java开发工具比较