這是一個簡單的數(shù)據(jù)生產(chǎn)導入的故事,原本故事情節(jié)應該是這樣的:數(shù)據(jù)整理-->測試驗證-->生產(chǎn)發(fā)布-->生產(chǎn)驗證,然后就是各回各家,所以這本來應該是一個平淡的故事,然而實際卻變成了如下情節(jié):數(shù)據(jù)整理-->測試驗證-->生產(chǎn)發(fā)布-->生產(chǎn)驗證-->校驗失敗(預期數(shù)據(jù)未導入)-->問題排查-->解決問題-->生產(chǎn)發(fā)布-->生產(chǎn)驗證-->校驗問題(大部分數(shù)據(jù)是正確的,少部分數(shù)據(jù)不正確)-->問題排查(當時未能排查出原因,但能判斷出異常與生產(chǎn)原有的幾條異常數(shù)據(jù)有關)-->異常數(shù)據(jù)刪除sql編寫-->測試校驗-->生產(chǎn)發(fā)布-->生產(chǎn)校驗-->重新導入刪除部分數(shù)據(jù)(異常數(shù)據(jù)這次直接排除,沒包括在導入范圍)-->部分異常數(shù)據(jù)請示領導修正-->修正Sql準備-->測試校驗-->生產(chǎn)發(fā)布-->修正數(shù)據(jù)對應數(shù)據(jù)導入-->生產(chǎn)校驗!
你以為到這里就結束了?NO NO NO,故事怎么可能就這么結束,因為這批數(shù)據(jù)導入有對應的其它業(yè)務,還需要執(zhí)行該部分業(yè)務,最終確認后才能各回各家,結果發(fā)現(xiàn),坑爹的數(shù)據(jù)庫數(shù)據(jù)是修正了,但因為程序采用了Redis,異常數(shù)據(jù)還在Redis中,所以還要在Redis中刪除該部分異常數(shù)據(jù),還好程序部分對此有處理,直接刪除沒導致程序功能異常,至此本次發(fā)布才算結束,但此時也已經(jīng)是凌晨0點了,這真是一個悲劇的故事……
首先需要介紹下本次導入的豬腳,一個預先寫好,且已經(jīng)發(fā)布至生產(chǎn)的存儲過程,另外該豬腳所在場景是MySql,其大致代碼精簡后如下
1 DROP PROCEDURE IF EXISTS `usp_SadEvent`; 2 DELIMITER $$ 3 CREATE PROCEDURE `usp_SadEvent` 4 ( 5 IN identityNo VARCHAR(20), 6 IN uName VARCHAR(15), 7 IN cAmount LONG 8 ) 9 label_at_start:10 BEGIN11 12 SELECT @uid := id FROM `user`13 WHERE identity_no=identityNo AND NAME=uName;14 15 IF @uid IS NULL THEN16 select identityNo,uName,0 ret;17 LEAVE label_at_start;18 END IF;19 update account set balance=balance+cAmount where uid=@uid;20 select identityNo,uN