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
不自己操作一遍，永远不知道这里面有多少坑！其他方法后续会补充。
