InfoQ|我不小心删除了生产数据库，还跑路吗？，作为创始人( 二 )
2.完善故障响应流程 ， 不同等级的问题系统由具体的负责人介入
为什么很多问题的修复进展不可控？一方面是需要团队协作；另一方面是临时去协调和熟悉问题 ， 排查问题的效率是比较低的 ， 可以考虑引入故障的等级分类 ， 及时通知相关团队 ， 把一些问题的处理作为预先处理的环节提前接入 。
3.运维操作需要报备
运维不做无准备的操作 ， 不做加塞操作（比如临时补充一些未经测试的脚本） ， 重要操作 ， 重大操作都需要报备 ， 及时通告 ， 把被动变为主动 。
4.引入审计流程 ， 实现独立的服务审计机制
审计环节是一个相对重要的独立环节 ， 可以引入服务审计机制 ， 可以通过独立的审计服务发现潜在的隐患 ， 及时督正问题 。
5.业务异常预警 ， 需要同步相关链路层
对于业务层的异常 ， 业务预警尤其关键 。 及时预警并同步到相关链路 ， 可以避免系统雪崩的情况 。
2、技术1.完善备份恢复体系 ， 使得恢复能够可控 ， 高效 。 比如 ， 基础备份（全备和增量备份）和热数据恢复(基于binlog的闪回技术)
备份恢复体系的建设是数据库建设的基础 ， 也是衡量服务可用性的最后一根稻草 ， 充分结合全量备份和增量备份 ， 提高恢复效率 。
举例来说 ， 下面是一个全量备份和增量备份方案 ， 实现一次全备 ， 永远增量的实现策略 ， 然后在这个基础上实现基于binlog的闪回 。
文章图片
2.集群环境的恢复是系统薄弱环节
系统服务之间互相依赖 ， 这是之前很少有人关注的 ， 所以毫无疑问 ， 这是一块硬骨头 ， 我们需要重点关注 。
3.使用回收站技术 ， 杜绝人为恶意/误删除
备份能够解决一些异常情况下的数据恢复 ， 但是效率相对不高 ， 从规范角度来说 ， 如何避免危险操作 ， 转而使用更加优雅可控的处理方式是我们需要思考的问题 。
Drop操作是默认提交的 ， 而且是不可逆的 ， 在数据库操作中都是跑路的代名词 ， MySQL层面目前没有相应的Drop操作恢复功能 ， 除非通过备份来恢复 ， 但是我们可以考虑将Drop操作转换为一种可逆的DDL操作 。
MySQL中默认每个表有一个对应的ibd文件 ， 其实可以把Drop操作转换为一个rename操作 ， 即把文件从testdb迁移到testdb_arch下面；从权限上来说 ， testdb_arch是业务不可见的 ， rename操作可以平滑的实现这个删除功能 ， 如果在一定时间后确认可以清理 ， 则数据清理对于已有的业务流程是不可见的 ， 如下图所示 。
文章图片
此外 ， 还有两个额外建议 ， 一个是对于大表变更 ， 尽可能考虑低峰时段的在线变更 ， 比如使用pt-osc工具或者是维护时段的变更 ， 这里就不再赘述了 。
4.服务权限设置 ， 需指定客户端权限
分业务管理主库和备份库是互联网行业的普遍惯例 ， 很多公司普遍都会授予运维较大的权限 ， 这也是导致很多故障发生的潜在隐患 。
在这方面我们可以参考如下的一张设计图（来自张文宇老师） ， 可以在多个环节发力 ， 改进权限问题 。
文章图片
5.上云是个好方法
技术专家认为数据放在云端的保险系数还是相对较高的 ， 因为云端有足够多的公共资源作为支撑 。 其中 ， 快照和异地远程复制灾备服务是云端提供的非常好用的功能 ， 建议大家使用 。 当发生数据删除时 ， 可以使用快照迅速恢复或者回滚到某个历史时刻 ， 然后再通过其他方法补平到最新数据状态；而云端异地远程复制灾备服务也是比较成熟的技术 ， 相比本地实施的容灾 ， 初期投入更加划算 。
推荐阅读
- 取消充电头，除了获利，手机厂商也面临巨大风险
- 除了 Markdown 编辑器，你还需要会用程序来处理它
- 除了华容网格、原子组件 OriginOS还有什么？
- 荣耀新品正式官宣！除了智慧屏，还有V40要来？
- 微信7.0.20正式更新！除了新增的微信豆，还有8个新变化
- 在美国当快递小哥赚钱吗？西瓜视频解析除了努力，运气也很重要
- 手机曲面屏真的好用吗？一不小心就会误触，真"反人类设计"了
- 除了5G，iPhone12还有四大卖点，比5G更亮眼
- 手机包|除了手机，再也装不下去了
- 大陆为什么没有台积电？除了技术和设备，任正非早已指出关键问题