【分享】半个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. 一定要严格按照步骤来进行操作。

宁愿延期，不要加戏。

7.我救了我同事

我是一个喜欢备份数据库的人，骚操作之前还特别谨慎。

不过同事踩了，在群里说数据库没了，求救，我到现场看到同事就是坐地板上，很冷的地方，t恤全都湿了，一头都是汗，头发都湿了，说话带抖的。

几个大牛在讨论数据恢复的事儿

然后我说我有上周的备份

同事两眼放光，张开血盆大口跳起来抱住我……一身臭汗啊喂！！

然后赚了好几顿饭

8.实习的时候删过测试库

实习的时候删过测试库，当时是全组的开发每人一个自己的测试库，但是是放在同一个MySQL服务上的。

干昏了把组里一个QA的测试库给干掉了~

后来组里的老司机教了我一个，对数据库直接操作时养成习惯不管干啥都先敲个begin; 确认没问题了再commit; 很多时候错误的SQL执行的时候就意识到了，这时候rollback还来得及~ 线上还没出过事故，有次上线时弄错了还好rollback回来了~

教我的那个老司机现在已经跳槽去别的公司了，但是我感觉这个习惯背后是有故事的，一直没有机会问问他~

9.过度兴奋删库

十年前吧，连续干了36小时，把存储过程调试完很兴奋，清理测试数据时顺手就把主数据表truncate了。

那感觉天塌下来一样！

抖了十分钟，想起来还好有备份，但当时没敢动。

把业务停了回去睡觉，怕一激动把备份truncate 了。

第二天找到兄弟陪着，把表恢复了。

10.我死了

记得去年在广西，核心网新加一个硬盘。

按规范新硬盘上之前要先格式化一下，简单的命令，一个回车下去搞定。

等格完，新硬盘安装完毕。

回去睡觉，第二天一早炸了，几十万用户挂了吧。

关键是还没有备份，后面的事情圈内人应该都知道了吧。

11.不小心没做过，恶意的遇到过

不小心没做过，恶意的遇到过，以前在某全球500强公司工作的时候，遇到过有人恶意把数据库连同备份删光光，发现后反馈给上级，花了巨资请很多公司恢复，还拿到专门的硬盘恢复机构，然后请了做安全方面的巨牛公司（好几家）查凶手，最后的结果是失败，既没有恢复，也没查出是谁干的，一来是内部的人不好查，因为很多人知道管理员密码，还记得密码是：（此处省略，可能会暴露身份，哈哈），这个删的人比较懂，应该是堵死所有能查他身份的路还有恢复备份的路（备份只有一份），我一直怀疑是某小哥哥干的，因为那天是他在公司的最后一天，转天的飞机出国了，是移民不回来，大家估计都怀疑是他，但没有证据，也不知道谁怎么得罪他了。

也可能是其他人想栽赃他。

里面最重要的是该公司进入中国以来的所有财务数据，好在有物理单据，老大也有招儿，联系本地高校，花小钱让一批大学生来帮助重新录入的。

录了三个月才补好，后来就加强了安全措施和多份备份。

管理员密码只有少数人知道了。

家贼难防。

end

来源：知乎https://www.zhihu.com/question/58802374

本文内容来自互联网，如果侵犯了您的权益，请联系管理员立即删除（附上内容地址）

锤子简历，名企精英都在用的专业简历，700万优秀人才选择的智能简历工具，注册即可免费领取简历模板！