数据库备份对于DBA来说是一项日常不可忽略，并且非常重要的工作。当遇到数据库灾难时，备份
就成了救命稻草。每天对从库进行一次完全备份，现在我们来假设一种场景：
1）、开发童鞋在主库上误操作了某张表，导致数据“脏”了；
2）、开发童鞋向DBA求助，希望能恢复该表数据到某一个时刻，假设是2016-10-22 11:04:00 ；
3）、每天一次全量备份一般是在凌晨进行的，假设凌晨5点开始备份，6点结束；
4）、根据开发童鞋的需求，如果直接拿当天的全量备份进行恢复，无法满足其需求。
面对上述这种情况，我们该如何是好呢？DBA在数据库面前，应该是无所不能的。此时我们可以
使用start slave until的用法，用当前的全量冷备+追binlog的方式，追同步到指定时间点。
现在来演示一遍具体操作步骤：
1、取当天全量备份，假设备份文件为：20143_20161022.sql（使用mysqldump备份，mydumper备份也一样可以）；
【其中全量备份语法为：
mysqldump -uxxx -h127.0.0.1 -P20143 --default-character-set=binary --master-data=2 --events --routines --triggers -A > /data/20143_20161022.sql】
2、将全量备份文件恢复到测试实例
/data1/mysql_root/base_phony/20143/bin/mysql -uxxx -S /tmp/mysql_20143.sock --default-character-set=binary < /data/10.53.176.143_20143.sql
3、从测试实例导出需要恢复的表的数据：
mysqldump -uxxx -h127.0.0.1 -P20143 --default-character-set=binary --events --routines --triggers test test_event > /data/20143_20161022_test_event.sql
4、导出需要恢复的单表数据之后，再将该单表数据导入到另一个空的测试实例：
/data1/mysql_root/base_phony/20143/bin/mysql -uxxx -S /tmp/mysql_20143.sock --default-character-set=binary test < /data/20143_20161022_test_event.sql
5、修改该测试实例的配置文件，增加同步过滤规则，让它只同步主库的test.test_event表，并且重启使生效
replicate-wild-do-table=test.test_event
6、测试实例change master to 生产环境的主库
change master to master_host='xxx',master_user='xxx',master_password='',master_port=20143,master_auto_position=1;
切记！此时先不要start slave
7、在主库上找到需要恢复到的时间点：2016-10-22 11:04:00的binlog文件和位置点：
/data1/mysql_root/base_phony/20143/bin/mysqlbinlog -vv /data/mysql_root/log/20143/mysql-bin.000004 --stop-datetime="2016-10-22 11:04:00" > /data/file_000004.log
8、cat file_000004.log文件末尾，找到对应的pos为：# at 4264163
9、在测试实例的从库上，使用start slave until指令：
start slave until master_log_file='mysql-bin.000004',master_log_pos=4264163;
10、验证数据是否恢复到了2016-10-22 11:04:00，看到表中最后一条记录是:
“2016-10-22 11:03:59”
12、全量恢复冷备，最后一条记录是：“2016-10-22 10:39:03”，star slave until之后，最后一条记录变成了：“2016-10-22 11:03:59”
证明恢复达到了预期的要求！
引用：