前言
最近顺丰又搞出一个热门：运维误删库事件！
看看有没有什么后路好走啊哥们~
正文
- 国内呆不下了，赶紧出国
首先，不要选动车，要选最近的一班飞机，尽快出国，能走高速走高速，不然选人少的路线。
没错，我们 DBA 都是常备护照的。
切记，注意看高德地图实时路况。
我们有个前辈就是删库之后开车就上二环，下午五点钟。警察到的时候他还堵在路上。
- 只不过是把数据干掉了
权限问题永远是大问题，做好权限回收，开发数据库和线上数据库分离，线上数据库管理权限（一般指修改表结构权限与删表权限）禁止回收，也不提供给业务直接用。
不然参考 0。
公司管理上，最好有自己的 DB 运维产品，线上数据库只允许查，改的话要有审批流程。
至于查数据要不要脱敏、导入导出流程，就看自己产品的规划和排期了。
至于 DBA 怎么保证不手滑，这个每个人有每个人的习惯。
- 删库什么的都是小 case
清理数据库之前一定要检查进程，是否存在数据库进程，如果存在则宁愿不搞也不要深夜搞。
公司清理数据库要有下线流程。下线一定要走流程。宁愿多租几天机房也不要丢掉数据。
不然参考 0。
原则是：
rm 文件之前先检查进程是否存在。
绝不手工 drop 库表，如果非要 drop，则应该写成 rename，truncate 也是类似，写成 rename 和 create table like 两条 sql。
删表之前可以根据表文件的最后修改时间进行再次确认，不确认就找人 review，有下线流程则走下线流程。
- 备份，备份，备在何处？
冷备，热备都要有，一定要每天一备。
冷备便是应对这种情况。
公司应该有自己的 DB 备份方案，并且保证执行到位。
４. 人算不如天算
关于这一点，可以单独拉一个大专题出来了，核心内容是 mysql 高可用。
简单起见，推荐这篇文章：避免硬件故障的核心解决方案是冗余。
硬件层面的 raid，软件层面的主从、热备都是为了保证某一个节点宕机，其他节点仍然能继续工作。
所有库都要有主从备份，一方面做读写分离，一方面也是为了备份、高可用。
即便有半同步复制，有些极端情况下可以认为，mysql binlog 没有同步到从库上，仍然可能存在 binlog 丢失（数据丢失）的风险。
所以应对这点，比较好的开源解决方案有 2：TiDB 和 Mysql GR。
- 升级也能失败？
说起来很简单，升级无非是：
准备升级
过程原理
手工升级后拓扑：
工具（mha）升级后拓扑：
- 操作之前有个流程
一般自己操作的时候，都不会有太多的顾忌。
但是要是拿给别人看，就要考虑一下了。
如果别人不只要看，还要 review，那这样就比较难犯重大的错误了。
如果有些操作需要夜间一个人搞，那么一定要提前列好准备，这个就比较正式了。
包括：
- 梳理具体的执行步骤、执行命令和每个步骤的预计结果。
- 如果某些步骤出错，是否要求回滚、预先制定回滚方案。
- 详细记录执行记录，每一步都要有反馈。
- 事先梳理好收尾工作。
- 强关联业务要事先通知，考虑到时间段和别的业务高峰，尽量让对方也安排人留守观察。
- 一定要严格按照步骤来进行操作。宁愿延期，不要加戏。
７. 留几个问题
- 如果你有机会进行 mysql 迁移和升级工作，你认为无法写入数据造成的影响大，还是写入脏数据造成的影响大？
- 如果数据库挂了，机器可以启动但是 mysql 进程无法启动，你这里又有昨天的备份可以恢复，你该怎么做？
3.想要删库完全不出问题，那么删库流程该怎么设计？
好了，公司还是要有自己的 DB 产品，再简陋也要有。
原文地址：http://blog.51cto.com/13732225/2178615