今天在公司被問到DB Migration是否會影響到要不要將 CLP 掛 Maintenance Page 一事,這問題還真是難倒我了。

  站在QA 立場,對於DB Migration會有不知道會不會Lock DB Table的不確定性,我們考量到如果IAM在做 Account DB Migration 的時候,雖然是做塞資料到新Table而已,但因為會Select 資料從舊Table,所以擔心此時CLPUser來註冊新產品跟帳號時,會因為DB Lock而失敗,但又無法確定這可能性多高,所以為確保安全,CLP會被上Maintenance Page

  不過問題來了,CLP有很多的User,一旦上Maintenance Page勢必衝擊客戶的使用經驗。更何況這變成之後的還有兩到三次的DB Migration都要掛Maintenance ,這中間要跟很多PartnerStack Holder 溝通,其成本之巨大,難以想像。

  所以我去找了我們最專業的DBA Ju姐問說有沒有辦法評估說DB Lock"會或不會"在做DB Migration時發生?

  於是我得到兩個評估這個問題寶貴知識:

  1. DB Lock 一般會發生在DB Migration Script需要做大量DeleteUpdate資料時,因為這兩個動作會必需鎖住Table 的部份page,如此就有可能造成DB Lock,但如果Script都是在做Insert新資料甚至是Insert into new table,那應該不會有DB Lock 風險。
  2. 擔心做DB Migration時某些使用者行為可能因為DB Lock造成影響,那就只要在非Production環境做DB Migration時進行這些Behavior的測試看會不會發生問題即可,這也是證明問題存不存在的一種方式。

而在秉持第一項知識做DB Lock評估時,應該考慮到所有欲評估之使用者行為背後所有相關的DB Table,並把這些TableDB MigrationScript放在一起由DBA幫忙評估,這樣就比較能知道DB到底會不會因為做MigrationLock某些Table而造成使用者受到影響了。

  真是長知識了!確實在評估產品該不該因為DB Migration而暫停Maintain時更應該審慎評估,尤其產品是很多客戶在使用時,這時候就必需要精準且科學的提供評估方式與測試方法來證明DB Migration的影響程度為何,既而下判斷,真是不經一事,不長一智呀!

 

2018629日星期五

arrow
arrow

    jackterrylau 發表在 痞客邦 留言(0) 人氣()