最近一篇文章《不小心删库是一种怎样的体验？》比较火，说说半个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.操作前有个流程一般自己操作的时候不会不要有太多的顾忌。但是如果给别人看，就得好好想想了。如果别人不光看，还要复习，那就更难犯大错了。如果有些操作需要一个人在晚上完成，一定要提前做好准备，比较正式。包括：1、梳理出每个步骤的具体执行步骤、执行顺序和预期结果。2、如果某些步骤出错，是否需要回滚，提前做好回滚计划。3、详细记录执行记录，每一步都有反馈。4、提前整理好收尾工作。5.强相关业务需提前告知。考虑到时间段等业务高峰期，尽量让对方安排人留下来观察。6、一定要严格按照步骤操作。我宁愿推迟也不愿增加戏剧性。七、留几个问题1、如果有机会迁移升级mysql，你觉得不能写数据的影响更大，还是写脏数据的影响更大？2、如果数据库宕机了，机器可以启动但是mysql进程无法启动，而你有昨天的备份可以恢复，怎么办？3、如果想删除数据库没有任何问题，应该如何设计删除数据库的流程？嗯，公司还是要有自己的DB产品，再简单也不行。
