目的

由于《数据库安全浅析》一文中，主要介绍了数据库安全方面的一些基本安全策略，缺少了必要的案例分析和处理过程。为了进一步丰富数据库安全的内容，特撰文案例篇，主要介绍数据库安全上遇到的案例和处理的流程。

案例1

在一个周五的下午，某部门开发人员将线上环境误认为日常环境进行开发测试。不知道是哪根筋不对，执行了一个delete语句，悲催的是忘记加where条件了，结局可想而知。然后一头冷汗的跑到DBA这里，请求支援。更悲催的是，CTO都知晓该事情，瞬间空间凝结啊，DBA同学开始苦逼的工作了。

环境介绍：

在介绍处理方法前，首先介绍一下当前的一些环境。目前服务器安装MySQL，配置为主主模式，binlog复制模式为mixed。最大的好处是，DBA每天都全量逻辑备份数据库(数据库的数据量并不是非常大，百GB级别)，binlog保留时间为7天，并且每天也会备份。

处理方法：

1、工作分工。由于备份是晚上凌晨备份的，所以工作内容主要分为两个方面：

a)第一，将备份通过切割工具，将该表的所有数据分离出来，由DBA1负责操作；

b)第二，解析binlog文件，将误操作之前到备份期间对该表的所有操作筛选出来，由DBA2负责。

2、备份切割。DBA1从几十GB的SQL文件中，利用工具将该表的所有数据解析出来。切割工具很多，不再过多介绍。但是在该处理过程中，发现切割消耗了很长时间，是不是可以有方法节省这个时间呢？这个问题在之后会进行详细的介绍。

3、解析binlog。DBA2解析binlog，将期间的binlog解析出来。该过程对DBA来说，基本上采用mysqlbinlog进行，筛选脚本还要自己去写。而问题是有没有一种方法可以避免这个过程呢？这个在之后进行详细介绍。

4、数据恢复。首先DBA1先恢复该表的备份，然后DBA2恢复解析出来的binlog。逻辑备份恢复是一个很漫长的过程，这个时间能不能减少呢？这个在之后也要进行分析和介绍。

处理完成，整个处理过程消耗了大约30分钟(CTO在盯着，是多么紧张啊)，可要知道这是周五啊，多么想早点回家啊，结果摊上这事情啊。

案例总结：

从以上案例中，发现有几个处理上是正确的，但是在很多处理上，如果之前采用了更好的方式，是可以避免的。

1、首先在遇到问题时，进行分工合作的方式，是团队中很重要的。在大家团队合作的情况下，可以节省一定的处理时间。这是一个优秀团队的体现。

2、备份切割过程用时较长，是因为逻辑备份采用mysqldump工具对全库进行备份，如果能够按照每个数据库、数据表进行备份的话，只需要解压就可以用了，避免切割过程，可以节省很多时间。

3、解析binlog过程也较麻烦，需要binlog按照库解析出来，然后通过脚本将该表的操作解析出来，进行恢复。如果能提前开发此类工具就可以减少编写脚本以及测试的过程。

4、逻辑备份恢复时间简直是噩梦，如果通过xtrabackup物理备份恢复的话，可能会减少恢复的时间。

5、跳出处理过程，如果我们在配置MySQL时，设置成row模式的话，是不是仅仅通过binlog就可以恢复呢。并且，alibaba的DBA提供了flashback工具，这样可能会使得恢复时间更少。

案例2

某个晚上，某台服务器的某个实例操作异常，IO、CPU资源吃紧，导致IP自动切换到备库，由于主备延迟，导致新的操作执行后，一会儿后，主库恢复，复制线程出现

“duplicate key”错误。大晚上遇到这种事情，真想骂脏话。收到告警，赶紧起来处理！

环境介绍：

当前服务器上部署了4个MySQL实例，其中两个实例上有应用，并且都有备库。采用MMM高可用方案，在无法连接到主库后，vip会主动飘到备库，备库继续提供服务。

处理方法：

1、将备库的slave线程停止，继续让备库提供服务，将主库的slave线程也停止。但是此时形成了单点，这是个很大的隐患。

2、分析主库上的binlog，将中间丢掉的数据补到备库上。这个过程要靠人肉来处理，非常痛苦。

3、对备库全量备份，恢复主库。备份采用的依然是逻辑备份，恢复过程漫长啊。可以取代的方法，在案例1的总结中已经进行了说明。

4、重新配置MySQL，搭建成高可用的MMM方案。真的高可用吗？将在接下来的总结中进行进一步的说明。

该过程持续了2个多小时，因为是两个实例啊，这是多么痛苦的事情啊。期间忙得焦头烂额，各种想骂脏话。终于体会到苦逼的DBA生活了吧！

案例总结：

通过以上简单的描述处理方法，同样存在一些问题，在总结中成长。

1、其中一个实例异常，导致其他实例也不能正常提供服务，如何进行资源隔离，这是一个比较大的话题，本人对cgroup有了一些学习，也产出了一些成果。大家可以在博客中查看相关的资料。在这里，我认为通过cgroup限制每个实例的资源，这样就不会影响其他的实例的正常提供服务了。但是目前cgroup还存在一些小问题，但是并不影响需求。

2、停掉slave后，形成了一段时间的单点，如果该过程中仍然出现异常处理的话，恐怕就会出现较大的故障。该过程中应该紧急做从库，防止长时间的单点问题。然后进行接下来的重做主库，恢复高可用配置。

3、MMM高可用方案真的高可用吗？实际不是的，从长期的应用中发现，monitor主动切换，都会造成数据的一致性问题。因此，主动切换是一个非常危险的事情，尤其是在没有做任何检查的情况下，就继续提供服务。解决自动切换造成的问题有几种方案：

a)跳过一定量的自增ID方式，继续提供服务，这样可以避免该问题的出现。

b)建立容灾实例，期间只提供对新数据的操作，故障前的数据冻结，等数据库恢复后，切回环境，将容灾实例的数据还原回之前的主库中。

c)统一ID生成器，避免自增ID造成的主键冲突问题。

总结

数据库安全方面的案例很多，仅仅将常见的两个案例，进行详细介绍和说明。在分析中可以发现：数据库备份时DBA的头等大事；团队合作是优秀团队的体现；资源隔离在多实例情况下，非常必要；高可用方案可以解决一些问题，但不是所有问题。

分析中，很多探讨性的话题，如果有什么好的想法，欢迎大家讨论。