【问题】
假设有这种场景，误操作DROP DB或TABLE，常规的恢复操作是还原全备份，并用mysqlbinlog追加到drop操作前的位置。
如果需要恢复的binlog的日志量比较大而我们只希望恢复某个DB或某张表，常规操作会花费较长的时间。
在网上看到了借助SQL Thread来应用binlog的方法，做测试验证是可行的。
【原理】
1、Binlog是MySQL Server产⽣的，记录数据库的逻辑变化
2、Relay-log 是Master/Slave结构中Slave的IO_thread从主库获取变更日志，记录到slave本地
3、binlog和Relay-log实际记录的内容是完全一致的
【实现思路】
1、将源服务器需要追加的binlog文件拷贝到目标服务器数据目录下，修改为relay-log的命名规范
2、CHANGE REPLICATION FILTER REPLICATE_DO_TABLE=(db1.t1);设置过滤只复制某个DB或某张表
3、然后使用START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS语法还原到指定的GTID位置
4、开启并行复制加速binlog应用的速度，最新的MySQL5.7.23可以使用基于WRITESET的并行复制
【测试脚本】
（以MySQL5.7下误DROP TABLE test.test1为例，5.6也可以用同样的思路，但位置信息和筛选信息的脚本有差异，下面脚本供参考）
1、源实例做全备
innobackupex --socket=/data/mysql/mysql-replica01/mysql.sock --user=root --password= /data/backup
2、清空目标实例数据目录并还原全备
innobackupex --apply-log /data/backup/2018-10-24_13-22-09
innobackupex --defaults-file=/etc/my.cnf.d/replica02.cnf --copy-back /data/backup/2018-10-24_13-22-09
3、修改数据目录文件权限
chown -R mysql:mysql *
4、启动目标实例
systemctl start mysqld@replica02.service
5、连接目标实例，随便指定一个master_host信息，这个命令只是为了标识目标实例是slave角色
CHANGE MASTER TO MASTER_HOST='192.192.192.192';
6、systemctl stop mysqld@replica02.service
7、清理数据目录下生成的relay-log相关文件
rm -rf *relay*
8、将源实例的binlog备份拷贝到目录实例数据目录下，并修改命名规则，并修改权限
cp /data/mysql/mysql-replica01/TEST-bin.000414 /data/mysql/mysql-replica02
cp /data/mysql/mysql-replica01/TEST-bin.000415 /data/mysql/mysql-replica02
mv TEST-bin.000414 TEST-relay-bin.000414
mv TEST-bin.000415 TEST-relay-bin.000415
echo './TEST-relay-bin.000414' > TEST-relay-bin.index
echo './TEST-relay-bin.000415' >> TEST-relay-bin.index
chown -R mysql:mysql *
9、systemctl start mysqld@replica02.service
10、依据还原目录下的xtrabackup_info文件指定Relay_Log_File位置，但注意需要将binlog文件名称替换为relay log的命名规则
CHANGE MASTER TO Relay_Log_File='TEST-relay-bin.000414',relay_log_pos=1126;
11、指定筛选条件，只还原某个DB或某个表
CHANGE REPLICATION FILTER REPLICATE_DO_TABLE=(test.test1);
12、还原到drop table之前的位置
START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS='86c67cfe-8b18-11e8-9e4c-246e965710f8:478351666';
13、将目标表导入到需要恢复的源实例
