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