逻辑备份，也就是通俗的mysqldump，我忘记做了，正确来讲，部署的时候用原来活动的服务器快照恢复的，什么服务存活脚本、数据备份脚本是有的，但是数据库连接没改到新库，导致备份出的sql文件是空的，空是因为原来活动的数据库搞完活动释放掉了。
所以，我是要等着接受舆论的制裁。。。背锅！当然背锅的还有另一个兄弟：开发实习生，听说是数据搞乱了：说奖品数量会乱，会出现一个奖品两个人领的情况。看到排除开发自己和项目程序外，有未知 sql 执行，需要凌晨12点观察下（我也陪着，因为要丢个404图，至于binlog恢复还在研究），可能是定时器问题（确实就是这个原因）。说没啥测试就直接上线了，最后给我吐槽到代码里都是领导的逻辑项目是按照领导想法做的，没有他的，他只是陪跑的存在。
废话少说，从昨天下午开始，就开始做各种挽救，查了有binlog日志。其实我之前没看到阿里会自动帮做binlog，看到有，至少对恢复还是有点底的。
思路无非就是从某个时间点的全量快照恢复，然后重新执行后续的binlog。
我一开始还以为将binlog转成人看的格式，多少能恢复点数据【https://www.cnblogs.com/boluoge/p/15719940.html】：
特意转了一下给他们看，原来没用
#mysqlbinlog -vv --base64-output=decode-rows mysql-bin.001445 > /home/mysql-bin.log
于是想用自建库来恢复，特意在公司内网准备了跟线上版本一致的mysql 5.7，看到需要清掉其他业务库，所以特意克隆个干净的mysql【参考：https://developer.aliyun.com/article/833118】
第一步就卡死了：
我们购买的是mysql 基础版，下载下来的文件格式只能是csv（纯数据）+ sql（数据表结构）形式，导进去就开始出错。
幸好没在这里纠结太久，不然搞死，今早7点醒来头发都没梳，立马提了工单，问是否支持自建库恢复操作，回复如下：
（1）在实例控制台》备份恢复里，按时间点恢复到新实例 （2）新实例无法恢复源实例的binlog日志的，建议您使用DMS的数据追踪单独恢复3、4号的表数据，参考文档：https://help.aliyun.com/document_detail/126449.html
确认到的信息就是：
（1）不支持自建库恢复数据（mysql买的基础版，不是高可用版），不然可以参考【https://help.aliyun.com/document_detail/41817.htm?spm=a2c4g.11186623.0.0.73467fbdSmrwpM#concept-41817-zh】，基础版下载下来完全不是 .xb 文件形式，而是长这样：
外层：数据库名 ——》 数据库表 ——》 表下由：data目录（纯表数据） 和 structure.sql（建表语句） 组成
（2）不支持在源实例数据库进行回滚数据，需要利用新实例恢复
（3）新实例不能直接用命令执行源实例binlog，要借助阿里的DMS工具（确实好东西），不然运行恢复命令还是有点复杂的
傻瓜式参考这个就行了：
https://help.aliyun.com/document_detail/126449.html
二、问题解决
1、源实例数据按时间点恢复到新实例
这里会弹出提示框，说只能用新实例恢复快照，选按量确认即可
最后会看到有两个数据库（一个源，一个新实例），跟原来的账号、数据库、权限设置一模一样
2、DMS的数据追踪恢复表数据
要先选中登录的源实例，因为只有源实例有6月2日12点40到6月4日零点的数据；作为恢复用的新实例只有6月2日12:40的数据
选择要回滚的表，时间范围，最后导出回滚脚本
3、普通数据变更工单回滚表数据到新实例
大家直接看链接。。。
最后感谢阿里云强悍的技术支持。还有最重要的事，下次活动，一定要开启数据库逻辑备份！心累（自找的）