不小心删库是一种怎样的体验？半个DBA的跑路经验总结。

摘要：最近这篇不小心删库是一种怎样的体验比较火，蹭个热度讲讲半个的删库经验。下线一定要走流程。冷备便是应对这种情况。公司应该有自己的备份方案，并且保证执行到位。包括梳理具体的执行步骤执行命令和每个步骤的预计结果。宁愿延期，不要加戏。

最近这篇《不小心删库是一种怎样的体验？》
（https://www.zhihu.com/questio...）比较火，蹭个热度讲讲半个DBA的删库经验。

大半夜的脑子比较糊涂，简单写一写。

部分内容仅限于mysql。

首先，不要选动车，要选最近的一班飞机，尽快出国，能走高速走高速，不然选人少的路线。
没错，我们DBA都是常备护照的。
切记，注意看高德地图实时路况。
我们有个前辈就是删库之后开车就上二环，下午五点钟。警察到的时候他还堵在路上。

权限问题永远是大问题，做好权限回收，开发数据库和线上数据库分离，线上数据库管理权限（一般指修改表结构权限与删表权限）禁止回收，也不提供给业务直接用。

不然参考0。

公司管理上，最好有自己的DB运维产品，线上数据库只允许查，改的话要有审批流程。至于查数据要不要脱敏、导入导出流程，就看自己产品的规划和排期了。

至于DBA怎么保证不手滑，这个每个人有每个人的习惯。

清理数据库之前一定要检查进程，是否存在数据库进程，如果存在则宁愿不搞也不要深夜搞。

公司清理数据库要有下线流程。下线一定要走流程。宁愿多租几天机房也不要丢掉数据。

不然参考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进程无法启动，你这里又有昨天的备份可以恢复，你该怎么做？

想要删库完全不出问题，那么删库流程该怎么设计？

好了，公司还是要有自己的DB产品，再简陋也要有。