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 深圳
