一. 前言
思科前员工离职后删库，直接损失达 240 万美元。今天这个事情竟然发生到我们公司身上，吓了一身冷汗。同胞们一定要注意数据库安全问题。安全无小事，不出问题没人重视，一出问题就是致命的。
我目前在一家科技公司担任研发总监工作。今天上午10点左右，我随机点击了一个线上APP的一个功能，发现数据没有了。以为是个常规的bug，把这个问题直接反馈给了测试主管。
下面试我们的聊天：
震惊： 生产环境表被覆盖了？？？而且不能还原！！！
我立马停下手头的工作，赶快找研发落实问题。这个时候研发、运维都聚在一起排查原因了。
最终发现一个库的重要核心表被清空了。我问了下运维，可以恢复到之前数据不，运维说由于binlog日志没开启，而且没有备份，还是单机的。没法还原！如果真没法还原，线上数据库有20多万的用户，还有充值的金额，这个影响是致命的。
二. 尝试寻找解决问题
听完运维说的无法还原，我的心一下子提到了嗓子眼，顿时压力倍增。但是表面故作镇定，因为我是他们的精神依靠，我一旦慌了，他们估计就更慌了。
这个时候还有人在讨论是可能是黑客攻击、误操作、代码问题等原因，我阻断了他们的讨论，先解决问题！稍作镇定，我开始梳理思路。人和任务分成以下3条线同步解决：
- 备份现有数据： 先把当前库的所有表备份一遍，以防当前是由于黑客或者恶意破坏者继续破坏。
- 运维继续寻找还原策略： 运维负责继续寻找还原策略，再次确认是否有binlog方案还原、事务回滚还原、是否有定时备份文件。
- 研发通过其他表还原： 由于表被清空的只有一张，是否可以通过其他表的关联关系，进行拼接组装还原该表。经过和研发讨论，可以通过其他表把数据还原90%。心想，90%如果能还原也不错了。马上安排研发通过查找其他表的方式进行sql拼装的工作。
三. 结果：
就这样三个方案同步进行了20分钟，这个时候第二个方案，也就是运维这边传来了喜讯：他发现他之前做了一个定时任务备份数据库策略。大家顿时兴奋了起来，赶快找到了出问题的时间节点，然后顺利找到了最近一次备份文件。立马进行了数据库表的还原。还原过程很快，还原后验证下线上的问题，一切正常，这下才把心放了下来。
四. 问题分析：
由于mysql数据库，我们没有开启日志的记录。无法统计的造成这次事故的具体原因是什么，只有通过以下方式进行分析原因：
1. 黑客攻击：如果黑客攻击的话，不应该只删除一张表吧。而且程序上面排查没有类似的不安全脚本执行操作。所以黑客攻击的可能性不大。
2. 离职员工恶意报复：这个也有可能，离职员工目前手里面有数据库的账号和密码。也是有操作的可能的。
3. 员工升级误操作导致： 这个理论上是最有可能的，但是今天没有升级程序。都说没动过数据库。（其实我觉得应该是有人动了，不承认）
五. 防止删库跑路策略
1. 服务器异地定时备份： 一定要做个定时任务脚本，每天至少要异地（至少是异服务器）备份2次。防止磁盘挂了、黑客攻击、误操作等导致数据库异常。
2. 开启Binlog日志： 一定要开启binlog日志，一旦出现问题，既能通过日志的方式恢复；又能查出操作记录，从而追责到人。
3. 数据库集群策略： 数据库最好有3台机器，一主两从，互相同步。读写分离。
4. 数据库账户、操作权限回收： 这个一定要有，要把数据库的用户和密码以及操作权限，从研发人员手中会受到运维手中。防止研发误操作、离职报复等损坏数据库。
5. 业务库分离： 不要把所有鸡蛋都放到一个篮子中。每个业务对应一个库，多个业务库和库之间是物理隔离的，就算是一个数据库挂了，其他库和业务正常运行，把影响范围降到最小。
