比技术更重要的事情

写在前面

不以规矩,不能成方圆

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


`数据库从删库跑路` 经常被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等。