my09_mysql指定时间点恢复之binlog start-position

场景描述

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

在远程服务器做的全备并已经恢复，同时使用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

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

转载于:https://www.cnblogs.com/perfei/p/9391410.html