這樣做資料清理，可以避免引發MySQL故障
劉書浩， 中國移動DBA，負責“移動雲”業務系統的資料庫運維、標準化等工作；擅長SQL/">MySQL技術領域，熟悉MySQL複製結構、Cluster架構及運維優化；具有自動化運維經驗，負責“移動雲”資料庫管理平臺的搭建。
通常來說，效能監控類業務場景具有資料匯入量大、表空間增長快的特點，為了避免磁碟空間被佔滿，並提高SQL執行效率，要定期對歷史資料進行清理。根據資料採集頻率和保留週期的不同，可在應用程式中植入不同的定時器用於刪除歷史資料。在業務上線初期，這種簡單的定時清理機制是有效的，但隨著業務增長，特別是當有資料激增的情況發生時，上述定時器有很大機率會失效，不僅無法清理資料，還會因事務長時間持有表鎖，引起資料庫阻塞和流控。
下面我就跟大家分享一個因清理機制失效引發資料庫故障的案例，並且給出如何通過分割槽表和儲存過程進行資料清理的工程方案。
一、問題回顧
今年年初我們生產環境曾短暫發生雲監控系統故障。經排查故障是由OP應用程式定期在效能庫刪除資料引起的，具體原因是delete事務過大超出PXC叢集同步複製寫入集，該事務在本地邏輯提交後，無法在叢集另外兩個節點同步，最終在本地回滾。因持有表鎖時間過長，阻塞大量執行緒觸發System Lock，引起資料庫流控，最終導致華北節點雲監控資料更新緩慢。
下面介紹下故障排查的過程：
1、Zabbix發出告警通知
Zabbix發出告警通知：“華北節點OP效能庫記憶體利用率超過80%”，時間為：2018/02/27 06:14:05。
注：OP 是“移動雲”門戶系統簡稱；OP效能庫用於存放使用者訂購雲產品的效能資料，架構型別為3節點的PXC多主叢集架構。
登入資料庫檢視，發現等待執行的執行緒數量激增，資料庫已處於流控狀態。 引發資料庫阻塞的SQL語句為：
DELETE FROM perf_biz_vm WHERE '2018-02-25 02:00:00'>CREATE_TIME
該語句由OP應用程式發起，用於刪除perf_biz_vm表兩天前的歷史資料，故障發生時執行時間已超過4個小時，看執行計劃預計刪除2億行資料。
最終該語句沒有執行成功，並引發資料庫流控。
2、故障發生的機理
這裡我們結合Galera Cluster複製原理具體分析一下故障發生的機理。
首先，Galera叢集節點間同步複製，主要基於廣播write set和事務驗證來實現多節點同時commit、衝突事務回滾等功能。
此外，事務在本地節點執行時採取樂觀策略，成功廣播到所有節點後再做衝突檢測，當檢測出衝突時，本地事務優先被回滾。如果沒有檢測到衝突，每個節點將獨立、非同步去執行佇列中的write set。
最後，事務在本地節點執行成功返回客戶端後，其他節點保證該事務一定會被執行，Galera複製的架構圖如下：
根據Galera複製原理，刪除事務在本地節點提交成功時，本地節點把事務通過write set複製到叢集另外兩個節點，之後各個節點獨立非同步地進行certification test，由於要刪除的資料量非常大，該事務已超過同步複製寫入集（生產環境中write set設定值為1G），因此，本地節點無法得到certification資訊，事務並沒有插入待執行佇列進行物理提交，而是在本地優先被回滾。
錯誤日誌如下：
因事務長時間持有perf_bix_vm表的X鎖，導致本地節點雲主機監控資料無法入庫，隨著等待執行緒的累積，本地節點執行佇列會越積越長，觸發了PXC叢集Flow Control機制。
該機制用於保證叢集所有節點執行事務的速度大於佇列增長速度，從而避免慢節點丟失事務，實現原理是叢集中同時只有一個節點可以廣播訊息，每個節點都會獲得廣播訊息的機會，當慢節點的執行佇列超過一定長度後，它會廣播一個FC_PAUSE訊息，其他節點收到訊息後會暫緩廣播訊息，隨著慢節點（本地節點）事務完成回滾，直到該慢節點的執行佇列長度減少到一定程度後，Galera叢集資料同步又開始恢復，流控解除。
3、導致故障的其它因素
OP效能庫發生流控時，本地節點“DELETE FROM perf_biz_vm WHERE '2018-02-25 02:00:00'>CREATE_TIME”語句執行佔滿了Buffer Pool（即生產環境innodb_buffer_ pool_size=128G）， 加上資料庫本身正常執行佔用的記憶體，使系統記憶體佔用率超過80%預警值，此時開啟華北節點OP控制檯，可以看到雲監控資料更新緩慢：
4、重建資料清理機制
截止到2月28日，歷史資料清理機制失效，導致業務表單表資料量高達250G，資料庫儲存空間嚴重不足，急需擴容。為消除資料庫安全隱患、釋放磁碟空間，我們決定在資料庫側使用分割槽表+儲存過程+事件的方案重建資料清理機制。
二、重建清理機制
通過分析上述故障案例，我們決定基於分割槽表和儲存過程建立一種安全、穩健、高效的資料庫清理機制。
通過檢視執行計劃可以看到，用Delete語句刪除資料，即使在命中索引的情況下，執行效率也是很低的，而且容易觸發System lock。因此，根本解決大表資料清理問題要引入分割槽表，刪除資料不再執行DML操作，而是直接drop掉早期分割槽表（DDL）。
因為執行Delete操作時write set記錄每行資訊，執行drop操作write set只是記錄表物理存放位置、表結構以及所依賴的約束、觸發器、索引和儲存過程等，當表的資料量很大時，採用drop操作要快幾個數量級。
分割槽表的另一個好處是對於應用程式來說不用修改程式碼，通過對後端資料庫進行設定，以表的時間欄位做分割槽欄位，就可以輕鬆實現表的拆分，需要注意的是查詢欄位必須是分割槽鍵，否則會遍歷所有的分割槽表，下面看一下具體的實施過程：
Step 1： 首先，建立分割槽表。 在這裡我們就以perf_biz_vm表為例，建立相同表結構的新表，並把它命名為perf_biz_vm_new，利用create_time索引欄位做分割槽欄位，按天做分割槽並與主鍵一起建立聯合索引，建立語句：
CREATE TABLE `perf_biz_vm_new` ( `CREATE_TIME` datetime NOT NULL COMMENT '效能採集時間', `VM_ID` varchar(80) NOT NULL COMMENT '虛擬機器ID', `PROCESSOR_USED` varchar(100) DEFAULT NULL COMMENT 'CPU利用率(%)', `MEM_USED` varchar(100) DEFAULT NULL COMMENT '記憶體的使用率(%)', `MEM_UTILITY` varchar(100) DEFAULT NULL COMMENT '可用記憶體量(bytes)', `BYTES_IN` varchar(100) DEFAULT NULL COMMENT '流入流量速率(Mbps)', `BYTES_OUT` varchar(100) DEFAULT NULL COMMENT '流出流量速率(Mbps)', `PROC_RUN` varchar(100) DEFAULT NULL COMMENT 'CPU執行佇列中程序個數', `WRITE_IO` varchar(100) DEFAULT NULL COMMENT '虛擬磁碟寫入速率(Mb/s)', `READ_IO` varchar(100) DEFAULT NULL COMMENT '虛擬磁碟讀取速率(Mb/s)', `PID` varchar(36) NOT NULL, PRIMARY KEY (`PID`,`CREATE_TIME`), KEY `mytable_categoryid` (`CREATE_TIME`) USING BTREE, KEY `perf_biz_vm_vm_id_create_time` (`VM_ID`,`CREATE_TIME`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='虛擬機器效能採集表' /*!50500 PARTITION BY RANGE COLUMNS(CREATE_TIME) (PARTITION p20180225 VALUES LESS THAN ('20180226') ENGINE = InnoDB, PARTITION p20180226 VALUES LESS THAN ('20180227') ENGINE = InnoDB, PARTITION p20180227 VALUES LESS THAN ('20180228') ENGINE = InnoDB, PARTITION p20180228 VALUES LESS THAN ('20180229') ENGINE = InnoDB, PARTITION p20180229 VALUES LESS THAN ('20180230') ENGINE = InnoDB) */
（ 上下拖動可見完整程式碼 ）
Step 2： 用新的分割槽表替換原有舊錶。 這裡需要注意的是，執行rename操作會對perf_biz_vm表的元資料進行修改，需提前檢查有無對此表的Delete、Update、Insert事務與DDL操作，否則衝突會產生元資料鎖（Metadata Lock）。
我們的做法是提前將業務側的定時器停掉，並在業務低谷時執行如下語句，將舊錶和新表通過rename的方式互換，讓新表納入使用。期間若有業務呼叫，則會短暫斷開業務。
rename table perf_biz_vm to perf_biz_vm_old;
rename table perf_biz_vm_new to perf_biz_vm;
Step 3： 檢視到新表有資料寫入，雲監控頁面資料顯示正常，說明業務恢復。雲主機監控資料的儲存週期是兩天，因此需要將舊錶兩天前的資料拷貝到新表，該步驟通過指令碼來完成，可參考以下指令碼：
程式碼如下： #!/bin/bash function insert(){ end_time="$1 $2" start_time="$3 $4" mysql -u'user' -p'passwd' << ! use monitor_alarm_openstack; set innodb_flush_log_at_trx_commit=0; start transaction; insert into perf_biz_vm select * from perf_biz_vm_old where create_time < '$end_time' and create_time > '$start_time'; commit; select TABLE_ROWS from information_schema.tables where TABLE_SCHEMA ="monitor_alarm" and TABLE_NAME="perf_biz_vm"; ! } base_time="2018-02-27 2:00:00" while true do #end_time=$(date -d "-1hour $base_time" +%Y-%m-%d" "%H:%M:%S) end_time=$base_time start_time=$(date -d "-1hour $end_time" +%Y-%m-%d" "%H:%M:%S) #base_time=$end_time base_time=$start_time echo "Cur_time: $(date +%Y%m%d" "%H%M%S)" | tee -a 1.log echo "Range: $end_time $start_time" | tee -a 1.log insert ${end_time} ${start_time} | tee -a 1.log sleep 2 done
（ 上下拖動可見完整程式碼 ）
Step 4： 編寫儲存過程用於定期建立新的分割槽，並刪除幾天前舊的分割槽：
delimiter $$ CREATE PROCEDURE `clean_partiton`(SCHEMANAME VARCHAR(64), TABLENAME VARCHAR(64)，reserve INT) BEGIN -- 注：該儲存過程適用於分割槽欄位型別為datetime，按天分割槽且命名為p20180301格式規範的分割槽表 -- 獲取最舊一個分割槽，判斷是否為reserve天前分割槽，是則進行刪除，每次只刪除一個分割槽 -- 提前建立14天分割槽，判斷命名不重複則建立 -- 建立 history_partition 表，varchar(200)和datetime型別。記錄執行成功的SQL語句 DECLARE PARTITION_NAMES VARCHAR(16); DECLARE OLD_PARTITION_NAMES VARCHAR(16); DECLARE LESS_THAN_TIMES varchar(16); DECLARE CUR_TIME INT; DECLARE RETROWS INT; DECLARE DROP_PARTITION VARCHAR(16); SET CUR_TIME = DATE_FORMAT(NOW(),'%Y%m%d'); BEGIN SELECT PARTITION_NAME INTO DROP_PARTITION FROM information_schema.partitions WHERE table_schema = SCHEMANAME AND table_name = TABLENAME order by PARTITION_ORDINAL_POSITION asc limit 1 ; IF SUBSTRING(DROP_PARTITION,2) < DATE_FORMAT(CUR_TIME - INTERVAL reserve DAY, '%Y%m%d') THEN SET @sql = CONCAT( 'ALTER TABLE ', SCHEMANAME, '.', TABLENAME, ' drop PARTITION ', DROP_PARTITION, ';' ); PREPARE STMT FROM @sql; EXECUTE STMT; DEALLOCATE PREPARE STMT; INSERT INTO history_partition VALUES (@sql, now()); END IF; end; SET @__interval = 1; create_loop: LOOP IF @__interval > 15 THEN LEAVE create_loop; END IF; SET LESS_THAN_TIMES = DATE_FORMAT(CUR_TIME + INTERVAL @__interval DAY, '%Y%m%d'); SET PARTITION_NAMES = DATE_FORMAT(CUR_TIME + INTERVAL @__interval -1 DAY, 'p%Y%m%d'); IF(PARTITION_NAMES != OLD_PARTITION_NAMES) THEN SELECT COUNT(1) INTO RETROWS FROM information_schema.partitions WHERE table_schema = SCHEMANAME AND table_name = TABLENAME AND LESS_THAN_TIMES <= substring(partition_description,2,8) ; IF RETROWS = 0 THEN SET @sql = CONCAT( 'ALTER TABLE ', SCHEMANAME, '.', TABLENAME, ' ADD PARTITION (PARTITION ', PARTITION_NAMES, ' VALUES LESS THAN ( "',LESS_THAN_TIMES, '" ));' ); PREPARE STMT FROM @sql; EXECUTE STMT; DEALLOCATE PREPARE STMT; INSERT INTO history_partition VALUES (@sql, now()); END IF; END IF; SET @__interval=@__interval+1; SET OLD_PARTITION_NAMES = PARTITION_NAMES; END LOOP; END $$ delimiter ;
（ 上下拖動可見完整程式碼 ）
Step 5： 建立名稱為clean_perf_biz_vm的事件，並在每天凌晨00:30:00的時候呼叫clean_partition儲存過程建立下一個新分割槽，並刪除兩天前的舊分割槽。
delimiter | CREATE DEFINER=’root’@’localhost’ event clean_perf_biz_vm on schedule every 1 day starts DATE_ADD(DATE_ADD(CURDATE(),INTERVAL 1 DAY),INTERVAL 30 MINUTE) ON COMPLETION PRESERVE do begin call clean_partition(‘monitor_alarm’,’perf_biz_vm’,’2’); end | delimiter；
Step 6： 處理perf_biz_vm_old舊錶，在業務低谷期執行如下操作：drop table if exists perf_biz_vm_old，Drop掉整張舊錶的時間約為3min，並釋放了150G的磁碟空間。需要注意的是，雖然drop table的時間較短，仍會產生短暫的阻塞，因為drop table觸發的是例項鎖，因此需要在業務低谷期進行操作，並實時觀察資料庫情況。
從下圖可以看到，實際drop過程中記錄到的等待接收佇列的長度瞬時值為169，最高達到202：
至此，改造全部完成，我們已在資料庫側建立起安全、穩健、高效的資料清理機制。
三、結語
雖然本方案強調了儲存過程的使用，但上述儲存過程是基於簡單的create和drop操作，並沒有涉及複雜的邏輯和計算。MySQL是OLTP應用，最擅長的還是增、刪、查、改這樣簡單的操作，對邏輯計算分析類的應用並不適合，所以儘量避免使用複雜的儲存過程。
當然，也並不是所有場景都適合使用分割槽表，在很多DBA看來分割槽表在某些場景下是禁止使用的，一般會採用切表的形式進行拆分，本方案中使用時間做分割槽欄位，應用程式中查詢語句基本都能命中分割槽，對於Select、Insert等語句的執行效能是有所提升的。
以上是關於資料清理做的一些分享，更多內容請繼續關注dbaplus社群後續文章！