前提:对mysql库进行全备和增量备份(全备就是对hive库进行完全备份,增量备份就是将mysql的binlog日志进行备份)
情景说明:由于误操作,将包含有多张表的数据库给误删了
要求:恢复误删的数据库
具体模拟故障过程与恢复操作步骤如下:
(1)首先创建hive库,创建一个before1表,插入一条记录,创建一个after1表,插入3条记录
mysql> use hive;
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
+------+
3 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)
(2)对hive库做个完全备份(记录日志位置,并设置字符集)
mysqldump -uroot -pxxx -h10.191.22.247 -F -R --master-data=2 --default-character-set=utf8 --single-transaction -B hive |gzip >/tmp/mysql_$(date +%F).sql.gz
(3)在hive库中的after1表新增2条记录,并更新2条记录,刷新日志
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
| 555 |
| 666 |
+------+
5 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)
mysql> flush logs;
(4)在hive库中的after1表新增2条记录,误操作,drop数据库hive
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
| 555 |
| 666 |
| 77 |
| 88 |
+------+
7 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)
mysql> drop database hive;
(5)恢复被误删除的hive库
(5.1)先记录下当前数据库的日志号,并刷新日志,当前最新日志为29
(5.2)将没有备份的日志都备份到其他目录下
cp /mnt/sata01/mysql/mysql-bin.000028 ./
cp /mnt/sata01/mysql/mysql-bin.000029 ./
(5.3)恢复hive的完全备份
gzip -d mysql_2018-12-18.sql.gz
mysql -uroot -pxxx
查看完全备份时的日志号和日志位置:
more mysql_2018-12-18.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000028', MASTER_LOG_POS=154; //可以看到完全备份时的日志是28,位置是154.那么可以从28日志的154位置开始往后进行恢复
根据查看到的日志位置,对154后面剩余的日志进行应用:(注意--start-position=154参数的使用)
mysqlbinlog --start-position=154 --database hive mysql-bin.000028|mysql -uroot -pRootlyl123@ -v hive
将删除hive库之前的日志29,30都进行恢复:(还有一个问题,现在不确定drop库的操作在不在29和30的日志里,所以需要在库里或库外查看一下日志里面的具体操作)
对于DCL操作,如建库删库都能在库里查看日志的事件,如果是DDL操作,在库里看日志事件是看不出来的
在库里查看:(发现该删库操作在End_log_pos 733之前)
mysql> show binlog events in 'mysql-bin.000029';
| mysql-bin.000029 | 597 | Write_rows | 161 | 637 | table_id: 142243 flags: STMT_END_F |
| mysql-bin.000029 | 637 | Xid | 161 | 668 | COMMIT /* xid=13757124 */ |
| mysql-bin.000029 | 668 | Anonymous_Gtid | 161 | 733 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000029 | 733 | Query | 161 | 825 | drop database hive |
| mysql-bin.000029 | 825 | Anonymous_Gtid | 161 | 890 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
在库外查看:如果想找DDL操作,需要到库外,对日志进行分析来查找:
mysqlbinlog -d hive --base64-output=decode-rows -v mysql-bin.000029 >29.sql
vi 29.sql //在里面过滤查找drop关键字,发现删除位置操作在733处
【SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 733
#181218 11:51:53 server id 161 end_log_pos 825 CRC32 0xd623fa5d Query thread_id=83772 exec_time=0 error_code=0
SET TIMESTAMP=1545105113/*!*/;
drop database hive
/*!*/;
# at 825
#181218 11:53:28 server id 161 end_log_pos 890 CRC32 0xe5188448 Anonymous_GTID last_committed=3 sequence_number=4 rbr_only=no
】
恢复所有数据到733前,即恢复hive库到删除操作之前:
mysqlbinlog --stop-position=733 --database hive mysql-bin.000029|mysql -uroot -pRootlyl123@ -v hive //注意stop-position参数的使用
(6)查看数据库,发现数据库和里面的表数据已经都回来了
mysql> select * from after1;
+------+
| id |
+------+
| 22 |
| 33 |
| 44 |
| 555 |
| 666 |
| 77 |
| 88 |
+------+
7 rows in set (0.00 sec)
mysql> select * from before1;
+------+
| id |
+------+
| 11 |
+------+
1 row in set (0.00 sec)