最近的一篇文章《不小心删库是一种怎样的体验？》（https://www.zhihu.com/questio...）颇受欢迎。说说半个DBA删除数据库的经验。半夜脑子比较乱，就简单写一下吧。部分内容仅限于mysql。0.如果在国内呆不下去了，就赶紧出国吧。首先，不要选择子弹头列车，而是选择最近的航班。尽快出国。没错，我们的DBA都有常备护照。记住，关注高德地图上的实时路况。我们一位学长删库后驱车前往二环，时间是下午五点多。警察赶到时，他还困在路上。1、就是为了杀数据。权限问题一直是个大问题。做好权限回收，将开发库与在线库分离，在线库管理权限（一般指修改表结构、删除表的权限）禁止回收，也是不提供直接商业用途。否则参考0。在公司管理方面，最好有自己的DB运维产品。在线数据库只允许检查，更改必须有审批流程。至于是否对数据和导入导出流程进行脱敏，就看自己产品的规划和调度了。至于如何保证DBA不失手，每个人都有自己的习惯。2.删除数据库是小case。在清理数据库之前，必须检查进程，看是否有数据库进程。如果它存在，你宁愿不做也不愿在深夜做。公司必须有一个离线流程来清理数据库。离线必须经过这个过程。宁愿多租机房几天，也不愿丢数据。否则参考0。原则是：在rm文件之前检查进程是否存在。切勿手动删除数据库表。如果一定要drop，应该写成rename。截断也是如此。它被写成两个SQL：重命名和创建表。在删除表之前，可以根据表文件的最后修改时间重新确认。如果您不确定，请找人进行审核。如果有下线流程，就下线。3、备份，备份，备份在哪里？冷热备份都要有，每天都要准备。冷备就是为了应对这种情况。公司应该有自己的DB备份方案，并确保落实到位。4、人算不如天算关于这一点，可以单独拉出一个大题目。核心内容是mysql的高可用。为简单起见，我推荐这篇文章：避免硬件故障的核心解决方案是冗余。硬件层面的Raid，软件层面的主从和热备，都是为了保证某个节点宕机，其他节点还能继续工作。所有库必须有主从备份。一方面做了读写分离，另一方面也是为了备份和高可用。即使是半同步复制，在某些极端情况下，可以认为如果mysqlbinlog没有同步到从库，仍然可能存在binlog丢失（数据丢失）的风险。所以针对这个问题，有2个更好的开源解决方案：TiDB和MysqlGR。5.升级会失败吗？说起来很简单，升级无非就是：准备升级：流程原理：手动升级拓扑后：工具（mha）升级拓扑后：6.运行前有个流程。但是如果给别人看，就得好好想想了。如果别人不光看，还要复习，那就更难犯大错了。如果有些操作需要一个人在晚上完成，一定要提前做好准备，比较正式。包括：梳理出具体的执行步骤、执行顺序以及每个步骤的预期结果。如果某些步骤出错，是否需要回滚，提前做好回滚计划。执行记录详细记录，每一步都需要反馈。事先整理好收尾工作。强相关业务必须提前通知。考虑到时间段等业务高峰期，尽量让对方安排人留下来观察。请务必严格按照步骤操作。我宁愿推迟也不愿增加戏剧性。7.留几个问题。如果有机会进行mysql迁移升级，你觉得是不能写数据的影响更大，还是写脏数据的影响更大？如果数据库宕机了，机器可以启动，但是mysql进程无法启动，而你有昨天的备份可以恢复，怎么办？如果你想删除数据库没有任何问题，你应该如何设计删除数据库的过程？嗯，公司还是要有自己的DB产品，再简单也不行。
