技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> MySQL --> DBA工作初体验之死里逃生

DBA工作初体验之死里逃生

浏览:2361次  出处信息

端午节到了,3天的假期可以好好放松下紧张了又一个月的神经,同时也可以总结一下近期的工作;遗憾的是,自从工作了就再也没能吃到老妈包的粽子了(姜米配上红豆、花生、大红枣,我的最爱)。

DBA的工作不知不觉已经经历了第二个月,比第一个月更加“凶险”――死里逃生(未知),我似乎成为了运维部的【问题焦点】,信任、仔细、积极、能力、诚实等等属性都面临着各方面的考验。曾经一度想逃离,工作的郁闷,自己内心的沉重,问题冒呀冒;我怕,真的开始怕了,怕打开终端执行每一条命令,怕后面又有什么问题在等着我,怕看到同事质问眼神,怕被领导冰冷的气场所笼罩,一点都不夸张,我甚至开始恐惧去公司,那个让我压抑的舞台,尽管我喜欢这份工作。第一次体会到工作带给我这么多的感受。庆幸的是,我坚挺了下来,学着慢慢调整心态;世界杯的到来也让我心情放松了很多,即便被开,也有理由――为了看世界杯休息一个月嘛,毕竟4年才一次,尽情享受一个个美妙和谐的夜晚.(Come on Portugal,Come on C’Ronaldo!)

为什么我会说自己随时可能被开,是因为在过去的一个月里,我犯了一个足以让我走人的过错,发生后公司追究责任,最后领导帮我顶了下来,说这不是一个人的过错,如果开服前QA能够测到这个问题,也就可以得到及时解决,不至于临时停服3个小时;其实,说到底,还是我工作出了问题,丢失了一周数据,最后,无论查与没查,查到还是没查到,是我错了。下面,就和大家聊聊一个低级失误导致的这场风波。

情景:由于南方机房网络极其不稳定,对于一个网游戏公司,网络的敏感,这是绝对不能接受的,在和IDC博弈之后,决定换机房,将南方服务切换到新选定的西安机房;而服务器没有再用南方机房的那批,是重新从公司找了一组,做好系统和所有服务发往西安机房。

方案:我的任务就是重新搭建一套游戏库。在具体实施之前,都会和具体某款游戏项目负责人一起讨论一下实施方案,对具体细节中可能出现的问题作出提前估计,即便这样我还是遭遇了欲哭无泪的那一个幕(嘎嘎…)。商量之后,有两个方案:1.停服后直接将南方服务器上数据库停服备份,然后将dump文件传至西安,或是将数据库相关目录大包压缩传过去,但是考虑到文件大网络传输慢的因素,为了尽快开服,放弃了这种最为稳妥安全的方案,也就是那一个刻开始,注定,我要经历这一劫难,选了option 2;2.通过复制的方案实现与南方主库同步然后切换主库,目前数据库架构是主从关系,A(南方主)->B(中心从),而方案是要将C(西安新主)作为B的从库,也就是下面这么一个复制架构:A->B->C,最终A、B、C三个库中的数据完全一样,关闭A,C将替代A,B将重新CHANGE MASTER TO A,切服完成。这样的好处是,节省时间,因为我们在公司打好服务后,在没有发快递之前,都可以让C尽情地去追B(事实上,也与A保持同步),服务器到了西安后,继续去追,事实上,同步是非常快的,因为我们的网络带宽很可观(嘿嘿),这个我感受颇深,即便理论上我们都知道Replication是个异步的过程,两边会存在先后,但是这种差别在某个良好的条件下,还是很和谐的。

事故:现实,总是那么真实,当开启服务后,不到15分钟,客服收到玩家电话,说他的状态还停留在一个周前,很多交易获得装备都没了,妈呀!!!晴天霹雳呀,立马发出公告关服,检查数据,发现交易物品表中的确少了一周的数据没有被记录。于是,就想是不是大从出了什么问题,查了之后一切正常和主库一样,那这是为什么呢?紧张焦灼的气氛下,大家并没有找到事故的原因。而当务之急,是要在最短时间重新开服。赶紧重南方服务器上dump一份全备,传到西安服务器上然后恢复,2个多小时后重新开服。这下大家少少歇了口气,领导马上,把我们负责这款游戏运维的同事叫到会议室里,开会分析问题,我陈述了我的所有操作步骤,大家一起分析,推断猜想,没有很信服原因。会议上,领导对我说了一段很意味深长的话,我很清楚自己处境,不到2个月接连发生大大小小的问题,我也很是惭愧,其实不用多说,我也应该自己离去了,信任真的是没有了,你怎么让大家相信你呢?!大家还怎么和你一起工作,难道每次都要为你一个人的失误担惊受怕吗?我的眼睛红了,除了能说抱歉,就是接下来尽快找到事故的原因,尽可能得到大家的谅解,此刻我也知道走人已经是迟早的事情了,因为,得到别人原谅的程度是和你之前所获得的信任程度成正比的。

原因:那天晚上就没有停止检索问题,第二天,依旧去想去查任何蛛丝马迹,errorlog、binlog、relaylog比较分析,还是没有什么头绪。于是,便在MSN上向realzyy请教我遇到的状况,一起分析过后还是没有得到满意的解释。下午,突然,同事说你的server id是不是别比主小呢,那样会导致问题,他很肯定就是这个原因,我发现C的server id在发生问题是,的确比B的小,我开始试验验证这个,发现的确改了server id后问题得到解决,A->B->C这次正常了。我就告诉了realzyy,他听了后很幽默的评论道:这是哪个猪头说的从库的server id要比主库大,不是这个原因。还给我举了个例子,A<->B互为主从的,如果按照那个理由,就没法实现了。但是,就是server id,提醒了我,我一查,正式了,真是我料到的A与C的server id相同都是1,也就是默认的没有做任何修改。realzyy,听到后很无语,发过来他的经典回复6个点,从那天下午开始,我对binlog、relaylog以及复制机制有了进一步的认识。

分析:有的朋友可能会问题,为什么至少了一周呢?是这样的,在C上我先用的是事故发生前一周的全备(每周全备一次)恢复到某一点,然后我通过dump文件中记录下的change master点位,去到接B,然后保持同步,追了一周,但实际上,这一周白追了,所有的修改并没有被同步到C上。有心的话,你一定会问如何让我的dumpfile中记录下主库的binlog的pos呢?在mysqldump的时候加上-master-data这个参数就可以了,它有1和2两个值。继续说,导致整个事故,结果却发现是一个很小白的失误――server id。只要是学习配置过MySQL Replication这一应用的朋友,在手册里面很醒目的提示就是要求我们必须保证,配置过程中server id必须唯一,但是,在这里我更想强调的是在整个复制体系中server id要保证唯一性,为什么我要强调整个复制体系呢?当我们配置A->B->C正中窜连的架构时,是两两配置的,先配置A和B,然后再配置B和C,这样就很容易忽略server id在整个体系中唯一,而且我们检查复制是否正常,通常也是检查A到B正常,B到C正常,那么我们就认为这个体系搭建成功了。而,我们认为复制正常的标准是什么呢,也就是show slave status看到两个YES,我们就认为okay了,看是与主同步的情况通过seconds_behind_master的秒数。但是,事实上,我出现问题这些都是正常的,每当我查看的时候都是YES,我就认为同步正常,但实际不是我们想的那么好。可能有人会问了,C上面少了一周的数据,那你的那个read_master_log_pos在变吗,和主库的位置一样吗?我很诚实的告诉你,真的是一样的。那你肯定疑惑了,位置也在变呀,说明relaylog已经同步过来了主库的执行语句,那么为什么实际表中没有记录呢?之前,我也有同样的问题。其实,relaylog中的语句没有被真的执行,如果只是被跳过没有被执行,那个position也一样会在不停的变化的。那为什么会跳过呢,我们并没有让它跳过已经复制过来的SQL语句呀?如果你打开过binlog或relaylog看过里面的内容的话,留心的话你会发现它们会记录server id的,每次sql线程是否执行log里面的语句是有条件的,会首先判断relaylog里面将要执行的这条语句中server id是否和自己相同,如果相同,那么他会认为是自己曾经执行过的,当然就没有必要再去执行一遍,这就是导致我的问题的关键所在,也是手册里面为什么重点强调server id必须要保持唯一的原因。这下真相大白。

教训:1.生产中,安全第一,绝对是怎么稳妥怎么来,无可厚非某些技术的使用可以提高效率,但是这是建立在你的能力基础上的,是否有足够的把握去控制它们?

2.不要把东西搞复杂,首先,出了问题不便于查找,其次,也给自己的管理增加了难度。(记得09年infoQ上优酷的架构师就反复提到这点,当时就那么一听没有任何感觉,有些东西,真的是只有亲身经历了才能体会到那些大牛们的内心感受,那样做不这么做,都是有它的原因的,所以经验是不能模仿的。)

上面就是这次严重事故背后的所发生的故事。全是文字,“洋洋洒洒”罗嗦了一堆,希望对大家多少有点帮助吧。从问题本身来看,是一个十分低级的错误,也可能在大家的工作中根本就不会发生跟我一样这么愚蠢的问题,那么,你应该是一个仔细认真,同时也理解了server id作用的DBA。总之,低级的背后还是有很多值得我们去思考的地方,以后不要在同一个地方跌倒,这次教训还是值的。

享受MySQL,享受世界杯。

建议继续学习:

  1. 我对技术方向的一些反思    (阅读:9945)
  2. Oracle DBA的学习进阶成长树-从初出茅庐到高瞻远瞩    (阅读:4487)
  3. oracle技术方面的路线    (阅读:3440)
  4. MySQL DBA修炼秘籍    (阅读:3247)
  5. 我的担忧:dba如何在稳定环境中成长    (阅读:3148)
  6. DBA有什么个人前途?    (阅读:2754)
  7. DBA最缺的不是技术    (阅读:2731)
  8. MySQL DBA面试全揭秘    (阅读:2749)
  9. 《Oracle DBA手记》一书推荐 - 感谢刘松先生    (阅读:2557)
  10. 应用DBA的价值    (阅读:2427)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
  • 作者:zhang    来源: SQL部落
  • 标签: DBA
  • 发布时间:2010-06-16 23:55:44
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1