一.数据恢复

1.1 创建数据库

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_数据库


创建数据库db02,里面创建表user,存入三条数据

1.2 第一次操作: 保存数据

假设现在是周三凌晨三点,我们数据库自动备份。

然后进行数据备份:

mysqldump -uroot -p --flush-logs --lock-tables -B db02>/root/db02.bak.sql -u、-p 这两个就不用说了。
–flush-logs:这个表示在导出之前先刷新 binlog,刷新 binlog 之后将会产生新的 binlog 文件,后续的操作都存在新的 binlog 中。
–lock-tables:这个表示开始导出前,锁定所有表。需要注意的是当导出多个数据库时,–locktables 分别为每个数据库锁定表,因此这个选项不能保证导出文件中的表在数据库之间的逻辑一致性,不同数据库表的导出状态可以完全不同。
-B:这个表示指定导出的数据库名称,如果使用 --all-databases 或者 -A 代替 -B 表示导出所有
的数据库。

以上命令执行完成后,会在 /root 目录下生成一个 javaboy.bak.sql 文件,该文件就是备份的 sql 文件了。

1.3 第二次操作: 添加数据

周四早上,又往数据库添加了两条数据

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_数据_02

1.4第三次操作:库db02被删除了

这个时候,数据库db01被删除了。

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_数据库_03

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_数据_04

1.5 开始进行数据恢复

把周三存到数据库中的sql文件给取出来,即恢复周三时候的db02中usr中存储的数据
``

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_mysqldump 恢复较大数据慢_05


mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_数据_06


发现我们的db02中只有周三的记录,周四插入的记录是不存在的,那我们要去哪里找周四的记录呢?binlog中。

开始从binlog中找到周四的记录

show master logs ;

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_sql_07

显然,logbin.00001是周三的数据,logbin.00002中的是周四的数据。

去查看logbin.000001中的数据
show binlog events in 'logbin.000002';

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_数据库_08

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_mysql_09

取得到commit的数据,就是我们周四完成一次插入数据时,保存在begin的数据

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_mysqldump 恢复较大数据慢_10

由于后面需要的一个命令没有操作的插件,我们去下载这个插件mysqlbinlog,然后复制到docker 下的包里面

docker cp mysqlbinlog mysql01:/usr/bin/

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_mysqldump 恢复较大数据慢_11

ls -a 查询权限,发现权限不足,没有可执行的权限

mysqldump 恢复较大数据慢 mysql数据恢复几个小时前_数据库_12

chmod +x mysqlbinlog给他增加权限

linux中输入这一行,即bash-4.2中输入即可
mysqlbinlog /var/lib/mysql/logbin.000002 --stop-position=764 --2640 --database=db02 | mysql -uroot -p

然后刷新mysql发现恢复了数据