目前背景就是1 该业务，完整备份+binlog（200个，每个256M）进行恢复到一个时间点，其中完整备份5分钟，binlog原来可能要20个小时，这个时间太长了，有啥优化方案快速恢复速度吗

解决方案：

如果需要恢复的二进制日志较多，较复杂，强烈建议使用MySQL自身复制来恢复binlog，而不要使用mysqlbinlog

方案一、直接将要恢复的binlog拷贝到relay log目录，并修改slave-info相关的文件，让MySQL把binlog当做relay log来执行

1)关闭当前实例 

2)将binlog拷贝到对应的relay log目录(datadir或者relay-log参数指定的目录) 

3) 打开relay-log-info-file参数指定的relay-log.info文件(默认是datadir目录下的relay-log.info文件)，修改文件前面两行。 这两行的意义分别是：当前执行的relay log文件；当前执行到relay log文件的位置(position) 

4) 打开relay-log-index文件(由参数--relay-log-index，默认是数据目录下的host_name-relay-bin.index)将需要恢复的binlog文件全路径列表存在该文件中  

5)启动数据库，并start slave sql_thread

方案二【其实就是felix那篇热备DR的改进版】为需要恢复的实例做主从，需要恢复的实例为DB，把全备恢复到DR上，DB上的binlog拷贝到DR上（具体操作是上面方案一的2,3,4，也可以不这么做，简单做DR就好不过这样还需要用I/Othread重新记录到中继日志中比较慢，还是人为同步relay log比较好，但是这是理论操作，我没有实践过，可能有的关键操作点把握不到），然后DR上change master到需要恢复的binlog位置利用SQL线程来进行恢复，把需要DB恢复的数据在DR上恢复。

 

注意点：

* 配置文件中建议加上skip-slave-start，以免在不需要时候slave线程自己开始执行了

* start slave的时候，可以通过start slave until的方式，控制slave执行到的位点

* slave执行的其实位点，则通过relay-log.info或者change master to来指定