比技术更重要的事情

写在前面

不以规矩，不能成方圆

因一个好心办坏事的悲惨故事引发的思考。

`数据库从删库跑路` 经常被DBA、运维调侃。因为这个操作是致命的！
* 如果你在甲方，那么能遇到删库跑路的机会还是很少的，三年遇到一次那都算多的；
* 但如果你在乙方，那么一个月一次都算少的。。。
* 在乙方，会遇到大公司，小公司，微型公司😂；有规范的数据库备份策略，也有压根儿就不知备份为何物的。

呼吁DBA提高自身修养，非DBA也要操作谨慎。

各种奇葩的”人为误操作”：

  • 某新零售科技公司-自建MySQL5.7-误操作Truncate导致业务故障
  • 某基金公司-阿里云RDS For MySQL5.7-误操作Update导致业务数据错乱
  • 某化妆品公司-阿里云RDS For MySQL5.7-误操作Alter导致业务数据错乱
  • 某公司-自建MySQL5.7-数据库服务器因磁盘空间异常宕机后误操作rm -rf 数据库的数据目录导致数据库无法启动
  • 某金融公司-自建MySQL5.7-数据库服务器异常断电后数据表空间损坏（数据量2T）

各种奇葩的”备份失效”

  • 我以为我备份了，其实备份脚本压根就没有跑
  • 我以为我备份了，其实最近一次备份是一个月前
  • 我以为我备份了，其实不仅没有备份，连binlog都没开，开了也没有设置row格式。
  • 我以为我备份了，也开了binlog日志，其实binlog日志只保留1天，全备份是7天前的。
  • 我以为我的数据不重要，没有备份，我删了，业务告诉我数据还要。

👏欢迎补充奇葩备份失败案例。

故事背景

今天我们遇到的案例是一个好心办坏事的悲惨故事。

我们暂且称主人公叫小A吧～

小A最近在做一个项目：阿里云金融云上将UAT环境的业务P 从深圳（华南2）迁移到 （上海）华东2。

故事的时间线🧵如下：

  • 2020年4月22日晚：业务应用已经迁移到了上海，数据库也迁移过去了，但是业务忘记切换数据库了（这里有坑🍌）。
  • 2020年4月23日晚7点57分：业务反馈无法访问数据库
  • 2020年4月23日晚7点58分：运维小A反馈：”我以为业务已经切了，就将深圳的数据库实例的 业务账号和db1库和db2库 都在控制台上删除了”
  • 2020年4月23日晚8点00分：运维同学发现：业务还连着深圳的库，压根没切到上海去。

三问小A

故事分析

故事到这里，我们先看一下问题出在哪里？

救援步骤

1. 解析binlog日志，确定误操作的两个时间点(先后删除了两个库🐂)
2. 从备份恢复的时间点开始恢复日志，并跳过误操作
3. 导入测试实例，验证表行数，开发侧验证数据
1. 实例开不出来，最终选择了一台已存在的测试实例
2. 200M的数据量通过控制台恢复到指定时间点耗时较长2小时

阿里云RDS For MySQL常用恢复方法

操作规范

* 误操作人只能知道大致的误操作时间
* 根据大致时间过滤数据
* 根据数据量取误操作前后多长时间（默认10分钟）

* 误操作表
* 误操作执行语句

* 自建数据库授权
* RDS添加白名单

* 获取误操作SQL执行具体时间
* 获取误操作SQL执行具体位置
* 全备份恢复+解析SQL
* 解析SQL+回滚SQL

操作工具

NkIwmhsDJV5dAEK

阿里云工具

不得不说阿里云的正向恢复工具越来越完善，目前已支持：

  1. 全库物理备份+binlog 恢复方式：控制台-克隆实例-指定备份集/指定时间点
  2. 单库逻辑备份+binlog 恢复方式：控制台-备份恢复-单库恢复-指定备份集/指定时间点/指定恢复目标（新实例，本实例不同库名）

另外阿里还提供额外付费的DBS备份工具（逻辑备份）：单库/全库 一键恢复到指定时间点

开源工具-binlog2sql工具

从MySQL binlog解析出你要的SQL。根据不同选项，你可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等。