幾種常見的 MySQL/PolarDB-MySQL 回收表空間方法對比
背景
為什么需要回收表空間？任何一個存儲或您購買的實例規(guī)格都有容量限制，并且根據(jù)存儲介質(zhì)不同，保存方式不同，相應(yīng)地成本也會不同。在線數(shù)據(jù)庫的存儲成本是比較高的，所以架構(gòu)師和DBA在系統(tǒng)設(shè)計之初就要考慮滿足未來幾年內(nèi)的業(yè)務(wù)需求，同時又能最大化地節(jié)省成本，這是比較合理的架構(gòu)布局和容量規(guī)劃的方法。而大多數(shù)系統(tǒng)是沒有經(jīng)過以上步驟直接上線的，這種隨著業(yè)務(wù)的發(fā)展在線數(shù)據(jù)會保留的越來越多，當存儲容量不夠時可以通過升級實例規(guī)格或硬件解決，但如果沒有更大的規(guī)格時，只能刪除數(shù)據(jù)回收表空間了。
回收表空間的常見方法
在刪除回收表空間時，通常有以下幾種方法：
編號 | 刪除方法 | 回收方法 | 適合場景 | 弊 |
1 |
| DROP TABLE A; | 保留數(shù)據(jù)少，刪除數(shù)據(jù)多；但要極短時間暫停源表上的數(shù)據(jù)寫入（通常毫秒級別完成）； | 可能會引起性能抖動 |
2 |
| ALTER TABLE A ENGINE=INNODB;/OPTIMIZE TABLE A; | 保留數(shù)據(jù)多，刪除數(shù)據(jù)少；建議DELETE時用DMS的無鎖數(shù)據(jù)變更(參考 | 可能會引起性能抖動 |
3 | ALTER TABLE A DROP PARTITION partition_name; | ALTER TABLE A DROP PARTITION partition_name; | 分區(qū)表 | 可能會引起性能抖動 |
4 | DROP TABLE A_0000/A_20100101; | DROP TABLE A_0000/A_20100101; | 已經(jīng)人為分表存儲設(shè)置,如：按取?；蛉掌诜直?/p> | 可能會引起性能抖動 |
針對DROP TABLE A可能會帶來的性能抖動可以通過阿里云內(nèi)核經(jīng)過特殊優(yōu)化Purge Large File Asynchronously(https://help.aliyun.com/document_detail/134095.html)默認已經(jīng)打開。
而對于ALTER TABLE的操作，目前業(yè)界開源的有g(shù)h-ost、pt-online-schema-change和OnlineSchemaChange，阿里云RDS MySQL也專門研發(fā)了無鎖結(jié)構(gòu)變更。本文針對幾種常見的表空間回收的方式做了測試，希望給開發(fā)或運維人員提供更穩(wěn)定的變更參考方式，保障生產(chǎn)環(huán)境的穩(wěn)定性。
各類工具對比
1.比pt-online-schema-change的trigger對原表影響較小
pt-online-schema-change的工作原理是創(chuàng)建和源表A一樣的表A_gst執(zhí)行DDL操作，同時在A上創(chuàng)建一個DML觸發(fā)器，然后將A中的數(shù)據(jù)拷貝到A_gst，在拷貝過程中產(chǎn)生的增量變更就用觸發(fā)器完成同步更新?？截惤Y(jié)束后執(zhí)行兩張表的rename操作完成變更。
2.OnlineSchemaChange
工作原理和pt-online-schema-change基本一致，不同的地方是它采用的是異步模式，在A_gst的基礎(chǔ)上創(chuàng)建了一張日志表，觸發(fā)器的條目更新將直接落在日志表中，后臺進程將日志表中的條目應(yīng)用到A_gst表。這樣整個流程上是異步的，也能夠控制回放速度。
3.gh-ost
與上面兩種變更流程基本一致，但是沒有使用觸發(fā)器的設(shè)計，所以增量變更的數(shù)據(jù)來源不是觸發(fā)器，而是Binlog文件。訂閱讀取該文件中A表的變更記錄，將記錄解析并應(yīng)用到A_gst表。這樣的數(shù)據(jù)對于gst表回放非常有利，binlog中存儲的都是A表的記錄，易于直接讀取和應(yīng)用。
4.DMS的無鎖結(jié)構(gòu)變更
采用了無觸發(fā)器的設(shè)計，能有效解決觸發(fā)器設(shè)計帶來的鎖、數(shù)據(jù)庫開銷等問題。同時和DTS的聯(lián)動，執(zhí)行表空間回收時會把臨時表也傳送到DTS，這樣DTS的同步下游鏈路不會中斷。
為了驗證DMS的無鎖變更的穩(wěn)定性，做了4次測試分別是：
- 編號34221藍色曲線，基準oltp_insert測試作為對比基線;
- 編號34222綠色曲線，基準oltp_insert測試+DMS的無鎖變更+ALTER TABLE [tbname] ENGINE=INNODB;
- 編號34237黃色曲線，基準oltp_insert測試+關(guān)閉DMS的無鎖變更+RDS kernel ALTER TABLE [tbname] ENGINE=INNODB;
- 編號34239灰色曲線，基準oltp_insert測試+關(guān)閉DMS的無鎖變更+RDS kernel OPTIMIZE TABLE [tbname];
以藍色基線為基準，從圖中可以看出綠色曲線相較于同樣是執(zhí)行回收表空間的黃色和灰色平穩(wěn)，但持續(xù)時間較長；綠色、黃色、灰色曲線到最后都會臨時表重命名成正式表的過程，最多2s。
測試結(jié)論
結(jié)合實際業(yè)務(wù)來說推薦性能比較穩(wěn)定的DMS無鎖變更+ALTER TABLE。使用DMS的無鎖變更可以打開DMS控制臺，在頁面頂部，選擇全部功能 > 數(shù)據(jù)方案 > 無鎖變更。
注意事項
- 不支持字符串類型的主鍵(dms是一塊一塊的拷貝，最大值和最小值確定拷貝范圍，然后分成若干塊拷貝，會用到很多min max計算范圍的SQL)
參考
如何用DMS進行無鎖結(jié)構(gòu)變更(https://help.aliyun.com/document_detail/98373.html)
關(guān)于optimize和alter的原理(https://developer.aliyun.com/article/579242)
