DBA解题集：学会数数

你会数数吗？很多人对这个问题大概是嗤之以鼻吧，因为小时候爸爸妈妈就教我们数天上的星星，地上的羊。因此大部分人第一反应我想应该是：“你在逗我吗？”也正是因为这种如此小儿科的简单到我们不愿意青眼相加的事情，让我们在日常的变更支持中屡屡将自己落入尴尬的状态，给玩家的体验、公司的利益、团队的影响带来负面的评价。


DBA在跑完一个变更脚本后，便是检查日志，查看变更过程的详情，最经常使用的也就是grep -Ei error.log，更有甚者，Oracle DBA转MySQL的可能还会有grep -Ei ora 这种惊人举动。那warnings呢？真的可以做到置之不理吗？我们在天涯明月刀落地TokuDB大概1-2个月后，某天业务运维反馈现网版本加字段时间很长，这和TokuDB支持在线加字段相悖，线下通过测试重演，发现MySQL 5.6用了新的时间类型，如果低版本含有时间字段，并且通过原地升级上来的，则无法使用TokuDB原生的在线加字段。对这个结果的发现，我们则是通过warnings日志，而实际上每次的DB版本变更也都是有这个warnings，只是我们“视而不见”。


所以，在这里我想提一个观点，便是任何变更我们都要数对的，而不是数错的。

那么我们如何才能做到数对的呢？也就是我们应该怎么数才能数对？


一方面，数内容。有个例子，12.24 号幻想世界22号大区DB切换后玩家数据回档，22号大区已经从26迁移到了194；但原DB 26未从平台系统下架，而本次22号大区做Slave又错误地用了原DB 26做源master，导致了22号大区拆分切换后DB的数据少了一个月。我们应该保证变更的内容是对的，从IP配置、克隆权限到同步数据等这些基础环节。


另一方面，数数量。MySQL DBA的话，如果有20条SQL，便一定得有20个QUERY OK的返回。同样举个例子，英雄联盟裁决之地大区10月20日stat DB切换slave后玩家战绩及战力数据丢失，DBA通过平台DB工具箱检查Slave的状态是否正常；贴入16个stat slave IP，该工具仅返回15个状态结果；DBA未注意到HN9的stat slave IP未输出结果。

Have Fun！

By linwaterbin 

In 深圳