前言：在實際項目中,我們可能會出現業務擴展,但是現狀卻無法滿足,需要對現有的表字段擴容或者增加字段等情況,但是如果數據庫的數據量如果過大,我們就需要考慮修改字段帶來的影響.在這里我分享一個我在實際項目上因為對字段進行擴容引發的事故。
一、背景
由於業務方提出需求,我們現在庫存無法滿足,經過溝通我們決定采用對庫存中的一個字段進行擴容,但是在擴容期間業務方反饋出現大量調用服務超時問題。
二、問題定位和原因
當業務方出現超時時候,我們就迅速的查看日志和我們服務管理平台,發現服務整體的響應時間變慢,然后就想起擴容問題,然后就停止擴容,經過分析發現,原來dba的同事修改字段采用的alter,導致在修改期間鎖表,這樣一來業務大量的請求就出現等待,而數據庫連接長時間無法被釋放,這樣一來就出現了業務方超時。
三、alter修改原理
- 先進行鎖表
- 創建一張臨時表
- 將老表的數據拷貝到臨時表中
- 修改源表名為old表,把新表的表名修改為源表名,刪除old表
四、熱修改原理
后來dba同事對數據量大的就采用pt-online-schema-change這個工具進行修改,下面我簡單說下原理,想研究更透徹可以網上找下教程自己去學習
- 創建一張臨時表(表結構則是修改后的表結構),並從源數據表向新表導入數據
- 創建觸發器,用於記錄從導入數據期間所有操作表(增刪改)的操作,主要用於拷貝后執行觸發器保證數據不會丟失
- 導入數據結束后短暫鎖表然后執行觸發器
- 修改源表名為old表,把新表的表名修改為源表名,刪除old表
- 刪除觸發器
五、后續問題規避
如果不到不得已不建議修改線上數據苦,如果真的修改注意下面幾點
- 找dba分析修改的源數據表需要鎖表的時間(數據量小采用alter,量大則采用熱修改)
- 是否可以接受鎖表的時間(如果不能接受則需要采用其他方式)
- 修改表安排在流量小的時候比如晚上6點后,並觀察dba數據連接池變化、日志變化、服務耗時的時長等,如果有異常停止修改