场景描述

*********************************************

在远程服务器做的全备并已经恢复,同时使用binlog server备份binlog

之后,删除了库中所有表,然后又重建一批表,并插入了大量数据,重建的表与原来的表有重名的表(比如sbtest1)

然后要求恢复删除之前其中一张表sbtest1的数据

 

恢复思路

************************************************

由于在远程服务器上做了全备,并已经进行了全备的恢复,那么就可以按以下思路进行

1. 从远程服务器备份的binlog中找到删除操作的事务位置之前的一个位置pos

2. 在远程服务器上创建一个只有对表sbtest1有所有权限的用户,用于只恢复sbtest1,从而跳过其他事务;此步非必需。

3. 找到全备的起点,也是恢复的起点(在备份时加master-data参数后,备份文件初始-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=190;)

 

恢复准备

**********************************************

全备起点
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000016', MASTER_LOG_POS=190;

原库设置数据
update sbtest3 set pad='扫此二微码,免费领取小礼品' where id=101;
update sbtest2 set pad='扫此二微码,免费领取小礼品' where id=101;
update sbtest1 set pad='扫此二微码,免费领取小礼品' where id=101;

误操作
update sbtest3 set pad='此活动已结束' where id=101;
drop table sbtest3;

确认误操作具体位置

mysqlbinlog --no-defaults --database=txdb -v -v --base64-output=decode-rows --skip-gtids --start-datetime="2018-07-31 16:10:00" --stop-datetime="2018-07-31 16:20:00" mysql-bin.000016> /tmp/3.sql

split -l 100000 3.sql s_



BEGIN
/*!*/;
# at 319
#180731 16:13:56 server id 3318  end_log_pos 416        Rows_query
# update sbtest3 set pad='扫此二微码,免费领取小礼品' where id=101
# at 416
#180731 16:13:56 server id 3318  end_log_pos 469        Table_map: `txdb`.`sbtest3` mapped to number 152
# at 469
#180731 16:13:56 server id 3318  end_log_pos 861        Update_rows: table id 152 flags: STMT_END_F
### UPDATE `txdb`.`sbtest3`
### WHERE
###   @1=101 /* INT meta=0 nullable=0 is_null=0 */
###   @2=150912 /* INT meta=0 nullable=0 is_null=0 */
###   @3='99505216625-44652318903-87633088031-12891470052-20814553735-53032754476-32543784485-39935334177-82742270613-55767522233' /* STRING(360) meta=61032 nullable=0 is_null=0 */
###   @4='46607138393-89004745809-36733255854-15721737050-37472852755' /* STRING(180) meta=65204 nullable=0 is_null=0 */
### SET
###   @1=101 /* INT meta=0 nullable=0 is_null=0 */
###   @2=150912 /* INT meta=0 nullable=0 is_null=0 */
###   @3='99505216625-44652318903-87633088031-12891470052-20814553735-53032754476-32543784485-39935334177-82742270613-55767522233' /* STRING(360) meta=61032 nullable=0 is_null=0 */
###   @4='扫此二微码,免费领取小礼品' /* STRING(180) meta=65204 nullable=0 is_null=0 */
# at 861
#180731 16:13:56 server id 3318  end_log_pos 888        Xid = 2071
COMMIT/*!*/;
# at 888
# at 949
#180731 16:15:53 server id 3318  end_log_pos 1017       Query   thread_id=20    exec_time=0     error_code=0
SET TIMESTAMP=1533024953/*!*/;



 

以上方法在mysql备份与恢复是通用的,一个全备,binlog,恢复的起点与终点。恢复的方法有好几种,下面举例说明几个。

 

最常用的恢复

**************************************************************

适用于小数据量,即全备的时刻距离故障的时刻产生的binlog量不多,基本上所需要恢复的数据在一个binlog文件中

mysqlbinlog --no-defaults --database=txdb --skip-gtids --start-position=190 --stop-position=888 mysql-bin.000016 > /tmp/rec.sql

注意:stop-position是commit标志前后的这个pos,它们是一样的,在本例中是 end_log_pos 888 与 at 888,它是一个事务的结束点,也是另外一个事务的开始点

确认一下/tmp/rec.sql文件的结尾,是否有删除的操作,确保不会再重复删除

mysql -uautomng -pAutomng_123 -P3319 --database=txdb < /tmp/rec.sql 

然后确认数据库,数据已经到预期的时间点上了



mysql> select pad from sbtest3 where id=101;
+-----------------------------------------+
| pad                                     |
+-----------------------------------------+
| 扫此二微码,免费领取小礼品              |
+-----------------------------------------+
1 row in set (0.01 sec)



从恢复机导出该表,然后再导入到误操作的库中

mysqldump -uautomng -pAutomng_123 -P3319 --databases txdb --tables sbtest3 > /tmp/sbtest3.sql

scp /tmp/sbtest3.sql mysql01:/tmp

/tmp/sbtest3.sql中默认已经带上删除表的语句了

DROP TABLE IF EXISTS `sbtest3`;

mysql -uautomng -pAutomng_123 -S /data0/mysql/log/bak/mysql_bak.sock txdb< /tmp/sbtest3.sql 

确认误操作数据库是否恢复



mysql> select pad from sbtest3 where id=101;
+-----------------------------------------+
| pad                                     |
+-----------------------------------------+
| 扫此二微码,免费领取小礼品              |
+-----------------------------------------+
1 row in set (0.00 sec)



回顾总结

此例版本mysql5.7.22

不自己操作一遍,永远不知道这里面有多少坑!其他方法后续会补充。