ROW 格式binlog 在MySQL5.6上的数据恢复实验

2023-11-10 来源：六九路网

5.6和5.7版本的MySQL，有个参数binlog_row_image，默认值为FULL，表示记录的是全部的binlog操作日志（仅在binlog_format=ROW时候生效）。此外binlog_row_image还可以是minimal，表示binlog记录的就只是影响后的行。如此一来使用ROW格式就能节约很多的磁盘空间。

因此，我们服务器上就可以直接设置binlog_format=ROW格式了，至于binlog_row_image设置为FULL还是minimal，各位就自行考虑了。

环境版本如下：

> SELECT @@version+-------------+| @@version   ||-------------|| 5.6.34-log  |+-------------+> SELECT @@binlog_format;+-------------------+| @@binlog_format   ||-------------------|| ROW               |+-------------------+

假设我们的操作都是在一个库里面执行的，MySQL服务器上只跑了这一个hellodb业务的数据库。

如果数据库多的话，还会增大恢复的难度，如下事例(下面的grant操作实例不够明显，但是差不多就是那个操作步骤)：

step1 准备一个全量备份：

mysqldump --flush-logs -A > /root/all.sql

step2 手工误操作删除部分数据

> use hellodb;> delete from scores where `StuID`=8 AND `ID`=14;# 模拟误操作删了1条用户数据,然后上报需要回滚操作。此时还有个线程，执行了 grant all on *.* to ‘abc‘@‘%‘; 假设这个grant操作的是管理员正常的操作。> delete from scores where `StuID`=5 AND `ID`=10;# 模拟再次误操作删了1条用户数据,然后上报需要回滚操作。................在我们发现操作错了，到汇报这期间，还要很多用户的正常操作，也造成了数据库的一些更新。例如下面这条插入的记录。........INSERT INTO students VALUES(100,‘www‘,100,‘F‘,3,5);................

step3 mysql停机

/etc/init.d/mysql stop

step4 导出相关的binlog

cd /data/mysql

看下最近的binlog文件，假如我这里看到的是 mysql.0000010 这个文件。

# 先导出一份binlog文件，mysqlbinlog --base64-output=decode-rows -vv mysql.000010 > /root/1.sql

vi /root/1.sql 找到刚才我们误操作的部分，类似如下(下面被我添加了部分注释)：

BEGIN  ---> 这个BEGIN-COMMIT要删除/*!*/;# at 662771   --->  注意这个Postion,回滚要用到#170116 15:21:31 server id 106  end_log_pos 662826 CRC32 0xc2733cd6     Table_map: `hellodb`.`scores` mapped to number 156# at 662826#170116 15:21:31 server id 106  end_log_pos 662873 CRC32 0x0d302d22     Delete_rows: table id 156 flags: STMT_END_F### DELETE FROM `hellodb`.`scores`### WHERE###   @1=14 /* INT meta=0 nullable=0 is_null=0 */###   @2=8 /* INT meta=0 nullable=0 is_null=0 */###   @3=4 /* SHORTINT meta=0 nullable=0 is_null=0 */###   @4=57 /* TINYINT meta=0 nullable=1 is_null=0 */# at 662873#170116 15:21:31 server id 106  end_log_pos 662904 CRC32 0x7bda6198     Xid = 1136COMMIT/*!*/;# at 662904  ---> 这个BEGIN COMMIT要保留,这个是用户的正常操作的sql#170116 15:21:42 server id 106  end_log_pos 663027 CRC32 0xa7dc153b     Query   thread_id=10    exec_time=0     error_code=0SET TIMESTAMP=1484551302/*!*/;grant all on *.* to ‘abc‘@‘%‘/*!*/;# at 663027#170116 15:21:49 server id 106  end_log_pos 663102 CRC32 0xa7570f25     Query   thread_id=10    exec_time=0     error_code=0SET TIMESTAMP=1484551309/*!*/;BEGIN  ---> 这个BEGIN-COMMIT要删除/*!*/;# at 663102  --->  注意这个Postion,回滚要用到#170116 15:21:49 server id 106  end_log_pos 663157 CRC32 0x20b81986     Table_map: `hellodb`.`scores` mapped to number 156# at 663157#170116 15:21:49 server id 106  end_log_pos 663204 CRC32 0x26d9f8b8     Delete_rows: table id 156 flags: STMT_END_F### DELETE FROM `hellodb`.`scores`     ### WHERE###   @1=10 /* INT meta=0 nullable=0 is_null=0 */###   @2=5 /* INT meta=0 nullable=0 is_null=0 */###   @3=7 /* SHORTINT meta=0 nullable=0 is_null=0 */###   @4=63 /* TINYINT meta=0 nullable=1 is_null=0 */# at 663204#170116 15:21:49 server id 106  end_log_pos 663235 CRC32 0x81f9c1d6     Xid = 1138COMMIT/*!*/;# at 663235#170116 15:22:59 server id 106  end_log_pos 663310 CRC32 0xb3b0508d     Query   thread_id=10    exec_time=0     error_code=0SET TIMESTAMP=1484551379/*!*/;BEGIN ---> 这个BEGIN-COMMIT要保留,这个是用户的正常操作的sql/*!*/;# at 663310   --->  注意这个Postion,回滚要用到#170116 15:22:59 server id 106  end_log_pos 663373 CRC32 0x17a48bfc     Table_map: `hellodb`.`students` mapped to number 152# at 663373#170116 15:22:59 server id 106  end_log_pos 663424 CRC32 0x0acbd405     Write_rows: table id 152 flags: STMT_END_F### INSERT INTO `hellodb`.`students`### SET###   @1=100 /* INT meta=0 nullable=0 is_null=0 */###   @2=‘www‘ /* VARSTRING(150) meta=150 nullable=0 is_null=0 */###   @3=100 /* TINYINT meta=0 nullable=0 is_null=0 */###   @4=1 /* ENUM(1 byte) meta=63233 nullable=0 is_null=0 */###   @5=3 /* TINYINT meta=0 nullable=1 is_null=0 */###   @6=5 /* INT meta=0 nullable=1 is_null=0 */# at 663424#170116 15:22:59 server id 106  end_log_pos 663455 CRC32 0x1f37c970     Xid = 1139COMMIT/*!*/;

step5 准备恢复的数据

mysqlbinlog mysql.000010 --stop-position=662771 > /root/22.sql                            # 导出step2中第一个DELETE前的数据mysqlbinlog mysql.000010 --start-position=662904  --stop-position=663027 > /root/33.sql   # 导出step2中这个正常的grant授权操作语句mysqlbinlog mysql.000010 --start-position=663310  > /root/44.sql                          # 导出step2中的那个正常的INSERT操作及其后面的全部SQL操作

step6 开始恢复数据

/etc/init.d/mysql start mysql < /root/all.sql mysql < /root/22.sqlmysql < /root/33.sqlmysql < /root/44.sql

step7 检查恢复后结果

> use hellodb;> SELECT * from students where `StuID`=100 AND `Name`=‘www‘;+---------+--------+-------+----------+-----------+-------------+|   StuID | Name   |   Age | Gender   |   ClassID |   TeacherID ||---------+--------+-------+----------+-----------+-------------||     100 | www    |   100 | F        |         3 |           5 |+---------+--------+-------+----------+-----------+-------------+> SELECT * from scores where `StuID`=8 AND `ID`=14;+------+---------+------------+---------+|   ID |   StuID |   CourseID |   Score ||------+---------+------------+---------||   14 |       8 |          4 |      57 |+------+---------+------------+---------+> SELECT * from scores where `StuID`=5 AND `ID`=10;+------+---------+------------+---------+|   ID |   StuID |   CourseID |   Score ||------+---------+------------+---------||   10 |       5 |          7 |      63 |+------+---------+------------+---------+

可以看到恢复的效果不错。

ROW 格式binlog 在MySQL5.6上的数据恢复实验

标签：row 格式binlog 在mysql5.6上的数据恢复实验

小编还为您整理了以下内容，可能对您也有帮助：

mysql数据没有备份误删了怎么恢复

打开mysql的bin log功能：
对于mysql也是支持增量备份，但要打开mysql的bin log功能。
我们修改mysql的配置文件。linux是/etc/my.cnf，windows是mysql的安装目录/my.ini
我们在[mysqld]下面加上log-bin一行代码，如下面。

[mysqld]

log-bin=mysql-bin

复制代码
加完后重起mysql即可。

某客户更新数据的时候，误删了数据库的内容，因为数据库做了主从，但是没有做备份（备份很重要啊！）幸好开启了bin-log，之后只好把整个日志的记录拿回来本地进行恢复。

之后自己也做了一个简单的测试，对数据进行恢复，具体如下：
1、新建一个表
CREATE TABLE `lynn`.`sn_test` ( `name` VARCHAR( 10 ) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL , `age` INT( 3 ) NOT NULL ) ENGINE = MYISAM;
2、插入多条数据
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn1', '1');
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn2', '2');
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn3', '3');
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn4', '4');
3、查看数据并删除
mysql> select * from sn_test;
+-------+-----+
| name | age |
+---------+---+
| lynn1 | 1 |
| lynn2 | 2 |
| lynn3 | 3 |
| lynn4 | 4 |
+---------+-----+
4 rows in set (0.00 sec)
mysql> delete from sn_test;
Query OK, 4 rows affected (0.00 sec)
mysql> select * from sn_test;
Empty set (0.00 sec)
4、mysqlbinlog恢复数据
mysqlbinlog mysql-bin.000006 > 1.sql
查看1.txt里面数据插入的纪录，把删除之前的数据进行恢复
mysqlbinlog mysql-bin.000006 --start-position=2471 --stop-position=2876 | mysql -uroot -p123
重新登录，查看数据，OK，已经成功恢复了
对于数据库操作，应该注意如下问题：
1、要常备份（全备，增量备份），出了问题可以最快恢复数据；
2、操作数据库前，要把需要操作的数据库或者表mp出来；
3、需要把bin-log打开，就算没有做上面的两步，也可以通过日志恢复数据

mysql数据没有备份误删了怎么恢复

解析如何通过Mysql的二进制日志恢复数据库数据（图文详解）

本篇文章主要介绍了详解如何通过Mysql的二进制日志恢复数据库数据，具有一定的参考价值，有兴趣的可以了解一下。

经常有网站管理员因为各种原因和操作，导致网站数据误删，而且又没有做网站备份，结果不知所措，甚至给网站运营和盈利带来负面影响。所以本文我们将和大家一起分享学习下如何通过Mysql的二机制日志(binlog)来恢复数据。

系统环境：

操作系统：CentOS 6.5 X64 (虚拟机)；

WEB服务：PHP+Mysql+apache；

网站：为方便，直接在本地用蝉知系统搭建一个DEMO站点；

操作步骤：

1.开启binlog功能及基本操作；

2.往站点添加数据；

3.刷新binlog日志；

4.删除数据；

5.binlog日志内容解析；

6.恢复指定数据；

1.开启binlog功能及基本操作

要使用Mysql的binlog日志功能，首先要在Mysql的配置文件中开启该功能，操作很简单。找到Mysql的配置文件，在文件中添加一行”log_bin = mysql-bin”即可。其实在我安装的各种Mysql环境中，该功能通常都是默认开启的。

开启binlog功能后，在mysql的数据库目录下就会有诸如mysql-bin.000001、mysql-bin.000002等文件，这就是mysql的二进制日志文件。每当mysql启动或手动刷新日志后都会新建一个二进制日志文件。

首先我们mysql命令行中，用”show master logs”命令查看已有的binlog文件。

2.往站点添加数据

在网站后台文章模块里，我添加了几条测试数据。

3.刷新binlog日志

此前mysql的binlog文件为mysql-bin.000001，并且在网站后台往数据库中添加了三篇文章。现在我们刷新binlog日志，会生成新的mysql-bin.000002文件，如下：

flush logs;

show master logs;

4.删除数据

这里我把刚才添加的三篇文章都删除掉。

5.binlog日志内容解析

Mysql的二进制日志文件记录的mysql的操作，比如刚才的删除操作，我们来看下日志文件的具体内容。

使用mysql的mysqlbinlog命令：

mysqlbinlog /data/mysql/mysql-bin.000002注意：因为我本地mysqlbinlog无法识别binlog配置中的default-character-set=utf8，所以这里我在命令中加上了” _no-defaults”才起作用，大家引以为鉴。

下面是日志内容部分截图：

6.恢复指定数据；

在通过mysql的binlog日志恢复数据时，我们可以指定恢复到具体时间点，这有点像服务器快照管理。所以我们现在要恢复刚才删除的那篇文章，可以从删除之前找一个时间点，并恢复到那个时间点即可。

有关mysqlbinlog命令的使用方法，我们可以通过mysqlbinlog的帮助命令进行查看，如下：

mysqlbinlog _no-defaults _help

如帮助文档所示，可以通过指定时间或指定位置来恢复数据，这里我以指定时间为例给大家演示。

我们来查看下日志文件mysql-bin.000001，如下：

mysqlbinlog -no--defaults /data/mysql/mysql-bin.000001

通过前面操作步骤我们知道，在删除数据之前，我们生成了mysql-bin.000002日志文件，所以我们只要恢复到这个时间点即可，上图中我已找到了这个时间。

命令如下：

代码如下:

mysqlbinlog _no-defaults _stop-datetime='2017-04-11 09:48:48'/data/mysql/mysql-bin.000001 |mysql _uroot _p123456

这时我们在看后台，发现刚才删除的三篇文章都已恢复回来了，从而到达我们期望的目的。

总结：

本文和大家分享了如何通过mysql的二进制日志文件恢复数据。但还是要提醒大家，在平时要做好网站数据备份，现在的一些主流CMS建站系统都会内置数据库备份功能，比如这里我用的蝉知系统，数据是网站的命脉，做好数据备份以避免后期不必要的麻烦或损失。

mysqlbinlog 怎么将数据库恢复到指定的时间

$request = curl_init('http://vps_ip/test.mp3');
curl_setopt($request, CURLOPT_POST, true);
curl_setopt(
$request,
CURLOPT_POSTFIELDS,
array(
'file' => '@' . realpath('/home/test.mp3')
));
curl_setopt($request, CURLOPT_RETURNTRANSFER, true);
echo curl_exec($request);
// close the session
curl_close($request);
>

mysqlbinlog 怎么将数据库恢复到指定的时间

mysql数据库怎样用日志恢复数据sql语句

要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnf or my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为-- log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：
SHOW BINLOG EVENTS /G
你还可以从命令行输入下面的内容：
mysql --user=root -pmy_pwd -e 'SHOW BINLOG EVENTS /G'
将密码my_pwd替换为服务器的root密码。
1. 指定恢复时间
对于MySQL 4.1.4，可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明，假设在今天上午10:00(今天是2006年4月20日)，执行SQL语句来删除一个大表。要想恢复表和数据，你可以恢复前晚上的备份，并输入：
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/bin.123456 /
mysql -u root -pmypwd
该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句，可能你想要恢复后面发生的活动。根据这些，你可以用起使日期和时间再次运行mysqlbinlog：
mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/bin.123456 /
mysql -u root -pmypwd /
在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。

mysql数据库怎样用日志恢复数据sql语句

为什么使用mysqlbinlog无法恢复数据

1. 以前我错误的认为mysql的日志可以恢复到任何时间的状态，其实并不是这样，这个恢复是有前提的，就是你至少得有一个从日志记录开始后的数据库备份，通过日志恢复数据库实际上只是一个对以前操作的回放过程而已，不用想得太复杂，既然是回放你就得注意了，如果你执行了两次恢复那么就相当于是回放了两次，后果如何你自己应该清楚了吧。

2. 要想通过日志恢复数据库，在你的my.cnf文件里应该有如下的定义，log-bin=mysql-bin，这个是必须的.binlog-do-db=db_test,这个是指定哪些数据库需要日志，如果有多个数据库就每行一个，如果不指定的话默认就是所有数据库.
[mysqld]
log-bin=mysql-bin
binlog-do-db=db_test
binlog-do-db=db_test2

3.删除二进制日志:
a.mysql> system ls -ltr /var/lib/mysql/bintest*;
mysql>reset master(清空所有的二进制日志文件)
b.purge master logs to 'bintest.000006';(删除bintest.000006之前的二进制日志文件)
c.purge master logs before '2007-08-10 04:07:00'(删除该日期之前的日志)
d.在my.cnf 配置文件中[mysqld]中添加:
expire_logs_day=3设置日志的过期天数,过了指定的天数,会自动删除

4.下面就是恢复操作了
特别提示，mysql每次启动都会重新生成一个类似mysql-bin.000003的文件，如果你的mysql每天都要重新启动一次的话，这时候你就要特别注意不要选错日志文件了。

(注意：下面有一些技巧，这些东西才是最宝贵的哟，普通的东东手册上都有，这可是我摸索出来的哟，别人我都不告诉他。

技巧1 :
在下面你将看到 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd 类似的语句，但是它一次只能操作一个日志文件，如果你变通一下变成这样 mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.0* | mysql -u root -pmypwd 那么它基本上就会表示出的所有的日志文件了，这样可解决你忘记在哪一个日志文件中的问题，当然你也可以用这种写法更完美,mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.[0-9]* | mysql -u root -pmypwd ，看到[0-9]*这个东东了吧，它表示以数字开头的任何字符，方便吧！

技巧2:
你可以通过--one-database 参数选择性的恢复单个数据库，example在下面，爽吧。
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test

技巧3:
如果你老人家已经使用过 /usr/local/mysql5/bin/mysqlbinlog --start-date="2005-04-20 9:55:00" /var/data/mysql5/mysql-bin.0* > /home/db/tt.sql 类似的语句将日志导成了ASCII文本文件，那么你就可以直接在phpmyadmin或者其它什么乱七糟八的的客户端里执行这个文件文件就行了，因为它本身就是一个标准的sql文件，比如想让文件里面的某些语句不执行，OK，it's easy,找到它们删除即可，然后再放进去执行就OK滴啦！这个可是灰常灰常的爽哟。。。。。。

技巧4:
我来给大家讲一下，下面这条语句都做了什么
mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd --one-database db_test
这是把mysql-bin.000001这个二进制文件里的内容转换成ASCII文件(也就是sql语句)，直接通过管道操作符"|"传输给 mysql这个程序，然后过滤掉其它数据库的语句，只在db_test里执行。

技巧5:
着了，多打了一个技巧，现在暂时没内容，等以后再加吧！！！
)

下面部份摘录自网上。

如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog工具来恢复从指定的时间点开始 (例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。关于启用二进制日志的信息，参见5.11.3节，“二进制日志”。对于 mysqlbinlog的详细信息，参见mysql手册8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。

要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnf or my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为-- log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：

SHOW BINLOG EVENTS G

你还可以从命令行输入下面的内容：

mysql --user=root -pmy_pwd -e 'SHOW BINLOG EVENTS G'

将密码my_pwd替换为服务器的root密码。

1. 指定恢复时间

对于MySQL 4.1.4，可以在mysqlbinlog语句中通过--start-date和--stop-date选项指定DATETIME格式的起止时间。举例说明，假设在今天上午10:00(今天是2005年4月20日)，执行SQL语句来删除一个大表。要想恢复表和数据，你可以恢复前晚上的备份，并输入：

mysqlbinlog --stop-date="2005-04-20 9:59:59" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd

该命令将恢复截止到在--stop-date选项中以DATETIME格式给出的日期和时间的所有数据。如果你没有检测到几个小时后输入的错误的SQL语句，可能你想要恢复后面发生的活动。根据这些，你可以用起使日期和时间再次运行mysqlbinlog：

mysqlbinlog --start-date="2005-04-20 10:01:00" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd

在该行中，从上午10:01登录的SQL语句将运行。组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到上午10:00前一秒钟。你应检查日志以确保时间确切。下一节介绍如何实现。

2. 指定恢复位置

也可以不指定日期和时间，而使用mysqlbinlog的选项--start-position和--stop-position来指定日志位置。它们的作用与起止日选项相同，不同的是给出了从日志起的位置号。使用日志位置是更准确的恢复方法，特别是当由于破坏性SQL语句同时发生许多事务的时候。要想确定位置号，可以运行mysqlbinlog寻找执行了不期望的事务的时间范围，但应将结果重新指向文本文件以便进行检查。操作方法为：

mysqlbinlog --start-date="2005-04-20 9:55:00" --stop-date="2005-04-20 10:05:00"
/var/log/mysql/mysql-bin.000001 > /tmp/mysql_restore.sql

该命令将在/tmp目录创建小的文本文件，将显示执行了错误的SQL语句时的SQL语句。你可以用文本编辑器打开该文件，寻找你不要想重复的语句。如果二进制日志中的位置号用于停止和继续恢复操作，应进行注释。用log_pos加一个数字来标记位置。使用位置号恢复了以前的备份文件后，你应从命令行输入下面内容：

mysqlbinlog --stop-position="368312" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd
mysqlbinlog --start-position="368315" /var/log/mysql/mysql-bin.000001 | mysql -u root -pmypwd

上面的第1行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所有事务。因为mysqlbinlog的输出包括每个SQL语句记录之前的SET TIMESTAMP语句，恢复的数据和相关MySQL日志将反应事务执行的原时间。

为什么使用mysqlbinlog无法恢复数据

如何通过mysql的日志恢复数据库加急求救

1、首先确定my.ini(Win系统)或my.cnf(Linux系统)是否有如下配置
[mysqld]
log-bin=mysql-bin
等号后面是文件名或者路径加文件名。
或者
用命令看是否开启binlog配置：
mysql> show master logs;
mysql> show binlog events g;
2、提供故障时点描述信息
3、如果开启了binglog那就可以按故障还原点或者时间点进行还原操作了
mysqlbinlog --start-position=
mysqlbinlog --start-datetime=
这里语法是进一步查询的线索，不知道你是什么OS、开发还是生产库？不能乱指挥。
【备份：做故障还原及数据恢复前切忌做好备份(数据文件以及日志文件)】

如何通过mysql的日志恢复数据库加急求救

mysql备份与恢复的实验报告在哪里

实验MySQL备份与恢复

一、实验内容：

1、使用SQL语句导入和导出表数据

2、使用客户端工具备份还原数据库

3、使用日志文件恢复数据库

二、实验项目：学生成绩数据库

创建用于学生成绩管理数据库，数据库名为XSCJ中，XSCJ数据库中包括三个表：xs(学生基本情况表)、kc(课程信息表)、xs_cj(成绩表)。。

三、实验步骤：(要求使用语句完成)

1、使用select into ……outfile导出xs表数据，导出文件名为xs.txt，要求每行记录结束回车换行；

81e797c2c6b2bf39e8224ee671ce647e.png

2、使用create table like语句创建一个与xs表结构相同的表xs1，并使用load data将xs.txt的数据完整的导入xs1表中，并查看xs1表；

ca530d320003432441251d6e51809ff6.png

3、使用select into ……outfile导出kc表数据，导出文件名为kc1.txt，要求字段之间用逗号隔开，字符型字段值用双引号括起来，每行记录以“->”开头，每行结束回车换行；

da32788bbec152b932b960b76d9c008d.png

4、使用create table like语句创建一个与kc表结构相同的表kc1，并使用load data将kc1.txt的数据导入kc1表中，要求导入数据是忽略前面3条记录，只导入课程名、课程号、学分三列的数据；

ffd68720a4ed8428b61cd6d1d65bcd02.png

5、使用mysqlmp备份xscj数据库中的xs表到文件xs2.sql中；

9c7c64de9fa61ec43e5ac175e6945d7d.png

6、使用mysqlmp备份xscj数据库到文件xscj1.sql中

0e5ace5913933fbf7c12a53f0bc99875.png

7、使用mysqlmp备份xscj数据库和mysql数据库到文件twodatabase.sql中；

380c089e0891b90861dacff3b50e7be8.png

8、使用mysqlmp备份MySQL服务器中的所有数据库到文件all.sql中；

a0b9d6cef91a0ad5c98985ff6b002a76.png

9、删除xs表，使用mysql命令将文件xs2.sql中的数据恢复到xscj数据库中

fb9e600c30fd5809d45a84af98830ba5.png

10、删除xscj数据库中的所有表，使用mysql命令将文件xscj1.sql中的数据恢复到xscj数据库中；

1d044046eb1957607aefe19f014f5c0c.png

11、将xs表中的数据清空，使用mysqlimport命令将xs.txt中的数据导入到xs表中。

9a000f99f8226008a6c1c8fc945f2a42.png

四、实验报告要求

1、实验报告格式要求

包括内容：标题、实验内容、实验步骤、实验中遇到的问题及解决方案

2、实验报告内容要求

(1) 标题参看实验指导标题+“实验报告”，如“实验一 MySQL的安装与命令初步实验报告”；

(2) 实验内容与实验指导中相同；

(3) 实验步骤中将自己实验中的每个步骤的命令和操作结果显示界面进行截图完善。

(4) 实验中遇到的问题及解决方案中如实地将自己的问题的解决过程记录出来。

3、实验报告提交要求

每次实验课结束之后，每个人需要提交实验报告，实验报告命名为：学号姓名

MySQL误删数据后切勿跑路

误删数据的几种操作

如何事前预防误删数据？

误删行数据恢复

误删行数据恢复可以使用 Flashback工具。

Flashback恢复数据的原理是通过修改binlog内容，拿回原库进行回放，前提是 binlog_format=row和binlog_row_image=FULL 。

在使用Flashback进行恢复的时候，不建议在主库上进行操作，比较安全的做法是恢复出一个备份，或者找一个从库作为临时库，在这个临时库上执行操作，然后再将确认过的临时库的数据恢复到主库。

误删库/表

drop table或者truncate table误删数据表无法通过Flashback工具恢复，因为binlog_format的格式即使是ROW模式，在binlog中记录的也只是一条drop table或者truncate语句，因此无法进行恢复。

此时恢复的方式需要全量备份加增量日志的方式进行恢复，因此要求数据有定期的全量备份，并且实时备份binlog。

假如某人在中午12点误删除了一个库里的某张表，恢复数据的流程如下：

mysqlbinlog恢复数据慢的原因？

如何更快的恢复误删的表？

在用备份恢复出临时实例以后，将这个临时实例设置成线上备库的从库：

假设此时备库的binlog已经被删除，那么需要去binlog备份系统找到删掉的日志文件拷贝到日志目录下，假设文件名是master.000001，打开日志目录下的binlog的index文件，在开头加入master.000001，让备库重新识别此日志文件

延迟复制备库

以上恢复都具有时间不可控性，如果采用上述步骤进行恢复，建议开发成工具（甚至可以做自己的DBA自动化平台），并大量测试后进行使用，避免手动误操作带来更大的问题。

一般的主备复制存在的问题是，假设主库上的表被删除，这个命令很快会被发给所有从库，进而导致从库的数据表也被一起误删除。

延迟复制备库是可以持续保持与主库有N秒延迟的备库。

假设这里N=3600，那么表示只要在1个小时以内发现了误删除，就可以的到备库上执行stop slave，再通过之前讲到的方法，跳过误操作的命令（比如将误删除的GTID加到实例集合中），就可以恢复出需要的数据。

rm误删

只要你的集群是高可用，如果rm删除了某个节点(只要不是恶意删除所有节点)，HA系统会自动开始工作，选出一个新的主库，从而保证集群工作。

显示全文

全部栏目

ROW 格式binlog 在MySQL5.6上的数据恢复实验