端午节到了，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. 我对技术方向的一些反思    (阅读：9660)
2. Oracle DBA的学习进阶成长树-从初出茅庐到高瞻远瞩    (阅读：4221)
3. oracle技术方面的路线    (阅读：3105)
4. MySQL DBA修炼秘籍    (阅读：2998)
5. 我的担忧：dba如何在稳定环境中成长    (阅读：2838)
6. DBA有什么个人前途?    (阅读：2581)
7. DBA最缺的不是技术    (阅读：2543)
8. 《Oracle DBA手记》一书推荐 - 感谢刘松先生    (阅读：2372)
9. 应用DBA的价值    (阅读：2349)
10. MySQL DBA面试全揭秘    (阅读：2385)