逻辑备份,也就是通俗的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、普通数据变更工单回滚表数据到新实例
大家直接看链接。。。
最后感谢阿里云强悍的技术支持。还有最重要的事,下次活动,一定要开启数据库逻辑备份!心累(自找的)