Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1356047
  • 博文数量: 107
  • 博客积分: 1715
  • 博客等级: 上尉
  • 技术积分: 3168
  • 用 户 组: 普通用户
  • 注册时间: 2012-04-18 18:42
个人简介

阿里巴巴DBA,原去哪儿网DBA。专注于MySQL源码研究、DBA运维、CGroup虚拟化及Linux Kernel源码研究等。 github:https://github.com/HengWang/ Email:king_wangheng@163.com 微博 :@王恒-Henry QQ :506437736

文章分类

全部博文(107)

文章存档

2014年(2)

2013年(38)

2012年(67)

分类: Mysql/postgreSQL

2013-05-07 23:17:25


目的

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

案例1

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

环境介绍:

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

处理方法:

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

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

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

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

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

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

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

案例总结:

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

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

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

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

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

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

案例2

         某个晚上,某台服务器的某个实例操作异常,IOCPU资源吃紧,导致IP自动切换到备库,由于主备延迟,导致新的操作执行后,一会儿后,主库恢复,复制线程出现 “duplicate key”错误。大晚上遇到这种事情,真想骂脏话。收到告警,赶紧起来处理!

环境介绍:

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

处理方法:

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

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

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

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

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

案例总结:

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

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

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

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

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

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

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

总结

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

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

参考

1、《数据库安全浅析》http://blog.chinaunix.net/uid-26896862-id-3569354.html

2、《cgroup的相关博文》http://blog.chinaunix.net/uid/26896862/sid-161800-abstract-1.html

阅读(3217) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

zhangshengdong2014-10-16 14:40:01

对于高可用,我认为不用自动切,而是通过人为分析后手动切换来的实惠。因为,有的时候,因为网络或者其他因素,导致数据库切换到另外一台服务器,真是让人感觉会嗝屁