PolarDB-X 2.0支持管理TTL表過期數據清理任務,您可以通過查看清理任務進度、狀態,并根據實際情況調整清理任務的速度、清理范圍等,以達到對清理任務和在線業務的平衡。
前提條件
實例版本要求如下:
引擎版本為MySQL 5.7時,實例版本必須是polardb-2.4.0_5.4.19-20240927_xcluster5.4.19-20240920及以上。
引擎版本為MySQL 8.0時,實例版本必須是polardb-2.4.0_5.4.19-20240927_xcluster8.4.19-20240924及以上。
TTL定義僅支持AUTO模式數據庫的分區表(不包括使用
Local Partition
的分區表 )。
啟動清理任務
啟動TTL表過期數據清理任務,有以下兩種方式:
定時自動啟動:通過設置TTL_JOB,系統按時自動啟動過期數據清理任務。
手動啟動:手動執行
ALTER TABLE CLEANUP EXPIRED DATA
語句,即可啟動過期數據清理任務。
系統最多支持2張TTL表同時執行數據清理任務,其余清理任務排隊等待執行。
使用說明
定時自動啟動
示例:
ALTER TABLE `my_ttl_tbl` MODIFY TTL SET TTL_ENABLE = 'ON';
說明為TTL表
my_ttl_tbl
打開自動清理過期數據任務的執行開關(該開關默認為關閉狀態)。ALTER TABLE `my_ttl_tbl` MODIFY TTL SET TTL_JOB = CRON '0 0 2 */1 * ? *' TIMEZONE '+08:00';
說明調整TTL表
my_ttl_tbl
的自動清理過期數據任務執行計劃(執行時間點和頻率)。TTL_JOB定義的調度時間是預期時間值,實際執行時間需要依賴它的前置任務是否完成(如果有多張TTL表正在執行清理,則需要等待其他任務完成)。
手動啟動
示例:
/*+TDDL:cmd_extra(ENABLE_ASYNC_DDL=true, PURE_ASYNC_DDL_MODE=true)*/ ALTER TABLE `my_ttl_tbl` CLEANUP EXPIRED DATA;
說明/*+TDDL:cmd_extra(ENABLE_ASYNC_DDL=true, PURE_ASYNC_DDL_MODE=true)*/
用于設置該DDL后臺異步執行,無須在當前會話同步等待返回結果。ALTER TABLE CLEANUP EXPIRED DATA
只支持TTL表。
計算清理范圍
TTL表采用的是“由遠及近分批清理”的清理算法,從最早的數據開始清理,每次只清理固定時間范圍的數據。
如下代碼修改表my_ttl_tbl
的TTL定義:
ALTER TABLE `my_ttl_tbl`
MODIFY TTL
SET
TTL_EXPR = `time` EXPIRE AFTER 1 MONTH TIMEZONE '+08:00'
該表的數據存活時間為1個月。
每次清理任務清理的時間范圍是數據存活的3倍,本例中為3個月。
假設當前時間為2023-10-01,在線表只需要保存最近1個月的數據,清理流程示例如下圖所示:
Day 1:
TTL定義的時間列其最小時間值為2022-10-05(MinValue),再根據清理的時間范圍(CleanupDataInterval,本例中為3個月。更多信息,請參見調整清理時間范圍。)得出本次清理的范圍為2022-10-05≤Time<2023-01-01。以此類推其他清理范圍分別是2023-01-01≤Time<2023-04-01、2023-04-01≤Time<2023-07-01、2023-07-01≤Time<2023-09-01。
Day 2:
同Day 1,清理時間列滿足2023-01-01≤Time<2023-04-01條件的數據,即2023-04-01為本次清理任務的上邊界(CleanupUpperBound)。
Day 3:
同Day 1,清理時間列滿足2023-04-01≤Time<2023-07-01條件的數據,即2023-07-01為本次清理任務的上邊界(CleanupUpperBound)。
Day 4:
與之前略有不同,清理時間列滿足2023-07-01≤Time<2023-09-01條件的數據,時間范圍為2個月。因為上圖中假設的當前時間為2023-10-01(Now),且TTL表被設置為保留最近1個月(ExpiredDataInterval,TTL表的數據存活時間)的數據,所以本次只能清理2023-09-01之前的數據,即2023-09-01為本次清理任務的上邊界(CleanupUpperBound)。
綜上所述,可以得出每次清理任務的上邊界(CleanupUpperBound)的計算公式為CleanupUpperBound=Min(MinValue+CleanupDataInterval,Now?ExpiredDataInterval)。
查看清理任務進度
查看TTL表的定義
您可以通過如下代碼查詢視圖INFORMATION_SCHEMA.TTL_INFO
,以獲取數據庫中所有TTL表的定義及其清理任務的調度開關狀態:
SELECT *
FROM INFORMATION_SCHEMA.TTL_INFO
WHERE TABLE_SCHEMA='ttldb' AND TABLE_NAME = 'my_ttl_tbl';
*************************** 1. row ***************************
TABLE_SCHEMA: ttldb
TABLE_NAME: my_ttl_tbl
TTL_ENABLE: OFF
TTL_COL: date_field
TTL_EXPR: `date_field` EXPIRE AFTER 2 MONTH TIMEZONE '+08:00'
TTL_CRON: 0 0 1 * * ? *
ARCHIVE_TYPE:
ARCHIVE_TABLE_SCHEMA: NULL
ARCHIVE_TABLE_NAME: NULL
ARCHIVE_TABLE_PRE_ALLOCATE: 12
ARCHIVE_TABLE_POST_ALLOCATE: 64
1 row in set (0.07 sec)
字段說明:
字段名 | 說明 |
TABLE_SCHEMA | TTL表的邏輯庫名。 |
TABLE_NAME | TTL表的邏輯表名。 |
TTL_ENABLE | TTL表是否打開自動清理。 |
TTL_COL | TTL定義的時間列。 |
TTL_EXPR | TTL定義的數據存活時間。 |
TTL_CRON | TTL定時任務的調度間隔的定義。格式為QUARTZ框架的CRON表達式。 |
ARCHIVE_TYPE | TTL定義的歸檔類型。默認值Columnar,表示按行歸檔。 |
ARCHIVE_TABLE_SCHEMA | TTL表所對應歸檔表所在邏輯庫名。若該TTL表沒有綁定歸檔表,則該值為NULL。 |
ARCHIVE_TABLE_NAME | TTL表所對應歸檔表所在邏輯表名。若該TTL表沒有綁定歸檔表,則該值為NULL。 |
ARCHIVE_TABLE_PRE_ALLOCATE | TTL表按照分區規則提前預建的分區數。 |
ARCHIVE_TABLE_POST_ALLOCATE | TTL表已創建的分區數。 |
查看TTL任務狀態
您可以通過查詢INFORMATION_SCHEMA.TTL_SCHEDULE
視圖,來獲取指定TTL表的清理任務的實時運行信息。
如下代碼查看TTL表my_ttl_tbl
正在運行的清理任務:
// 手動調起清理任務
ALTER TABLE `my_ttl_tbl` CLEANUP EXPIRED DATA;
SELECT *
FROM INFORMATION_SCHEMA.TTL_SCHEDULE
WHERE TABLE_SCHEMA='ttldb' AND TABLE_NAME = 'my_ttl_tbl';
+--------------+------------+--------------------------------------+---------------------+
| TABLE_SCHEMA | TABLE_NAME | METRIC_KEY | METRIC_VAL |
+--------------+------------+--------------------------------------+---------------------+
| ttldb | my_ttl_tbl | SCHEDULE_STATUS | DISABLED |
| ttldb | my_ttl_tbl | SCHEDULE_EXPR | 0 0 1 * * ? * |
| ttldb | my_ttl_tbl | SCHEDULE_COMMENT | at 01:00 |
| ttldb | my_ttl_tbl | SCHEDULE_TIMEZONE | +08:00 |
| ttldb | my_ttl_tbl | SCHEDULE_LAST_FIRE_TIME | 1970-01-01 08:00:00 |
| ttldb | my_ttl_tbl | SCHEDULE_NEXT_FIRE_TIME | 1970-01-01 08:00:00 |
| ttldb | my_ttl_tbl | TTL_CURR_TTL_COL_MIN_VAL | null |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANUP_BOUND | 2024-05-01 00:00:00 |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANUP_UPPER_BOUND | 2024-05-01 00:00:00 |
| ttldb | my_ttl_tbl | TTL_CURR_NEW_DATETIME_VAL | 2024-07-18 18:22:54 |
| ttldb | my_ttl_tbl | TTL_CURR_JOB_STAGE | Finished |
| ttldb | my_ttl_tbl | TTL_CURR_JOB_BEGIN_TS | 1721298173321 |
| ttldb | my_ttl_tbl | TTL_CURR_JOB_END_TS | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_JOB_FROM_SCHEDULER | false |
| ttldb | my_ttl_tbl | TTL_CURR_JOB_STOP_BY_MAINTAIN_WINDOW | false |
| ttldb | my_ttl_tbl | TTL_CURR_DN_ROWS_SPEED_LIMIT | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANED_PHY_PART_COUNT | 8 |
| ttldb | my_ttl_tbl | TTL_CURR_TOTAL_PHY_PART_COUNT | 8 |
| ttldb | my_ttl_tbl | TTL_CURR_JOB_PERCENT | 100 |
| ttldb | my_ttl_tbl | TTL_ACQUIRE_PERMITS_AVG_RT_NANO | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANUP_TIMECOST | 6044 |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANUP_ROWS | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANUP_ROWS_SPEED | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANUP_DATA_LENGTH | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_CLEANUP_SPEED | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_SELECT_SQL_AVG_RT | 844 |
| ttldb | my_ttl_tbl | TTL_CURR_DELETE_SQL_AVG_RT | 2857 |
| ttldb | my_ttl_tbl | TTL_CURR_OPTIMIZE_SQL_AVG_RT | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_ADD_PART_AVG_RT | 0 |
| ttldb | my_ttl_tbl | TTL_CURR_DATA_FREE_PERCENT_LIMIT | -1 |
| ttldb | my_ttl_tbl | TTL_CURR_TTL_TBL_DATA_FREE_PERCENT | 0.00 |
| ttldb | my_ttl_tbl | TTL_CURR_OPTIMIZE_TTL_TBL_PROGRESS | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_JOB_FROM_SCHEDULER | false |
| ttldb | my_ttl_tbl | TTL_LAST_TTL_COL_MIN_VAL | |
| ttldb | my_ttl_tbl | TTL_LAST_CLEANUP_BOUND | |
| ttldb | my_ttl_tbl | TTL_LAST_CLEANUP_UPPER_BOUND | |
| ttldb | my_ttl_tbl | TTL_LAST_JOB_BEGIN_TS | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_JOB_END_TS | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_SELECT_SQL_AVG_RT | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_DELETE_SQL_AVG_RT | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_OPTIMIZE_SQL_AVG_RT | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_ADD_PARTS_SQL_AVG_RT | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_CLEANUP_TIMECOST | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_CLEANUP_ROWS | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_CLEANUP_ROWS_SPEED | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_CLEANUP_DATA_LENGTH | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_CLEANUP_SPEED | 0 |
| ttldb | my_ttl_tbl | TTL_LAST_TTL_TBL_DATA_FREE_PERCENT | 0 |
+--------------+------------+--------------------------------------+---------------------+
48 rows in set (0.03 sec)
字段說明:
部分指標名 | 含義 |
SCHEDULE_STATUS | 定時任務的調度開關:
|
SCHEDULE_EXPR | 定時清理任務調度時間間隔,該值可調整。具體操作,請參見調整定時清理任務的執行計劃。 |
SCHEDULE_COMMENT | SCHEDULE_EXPR字段的語義解析。 |
SCHEDULE_TIMEZONE | 定時任務調度的時區。 |
SCHEDULE_LAST_FIRE_TIME | 上一次觸發自動調度的時間值(初始值為 '1970-01-01 08:00:00', 表示沒有觸發自動調度)。 |
SCHEDULE_NEXT_FIRE_TIME | 下一次觸發自動調度的時間值(初始值為 '1970-01-01 08:00:00', 表示沒有觸發自動調度)。 |
TTL_CURR_TTL_COL_MIN_VAL | 當前清理任務的TTL定義的時間列的最小值。 |
TTL_CURR_JOB_STAGE | 當前清理任務所處的階段。 |
TTL_CURR_CLEANUP_BOUND | 當前清理任務正在清理的時間列的值。 |
TTL_CURR_CLEANUP_UPPER_BOUND | 當前清理任務的清理上界,即本次清理歷史數據的范圍小于該值。 |
TTL_CURR_NEW_DATETIME_VAL | 當前時間。 |
TTL_CURR_DN_ROWS_SPEED_LIMIT | 當前清理任務的清理限速(每個存儲節點執行 |
TTL_CURR_CLEANUP_ROWS | 當前清理任務已經清理的總行數。 |
TTL_CURR_CLEANUP_ROWS_SPEED | 當前清理任務的實時清理速度,單位是每秒清理的行數。 |
TTL_CURR_CLEANUP_DATA_LENGTH | 當前清理任務已經完成清理的總字節數(估算值)。 |
TTL_CURR_CLEANUP_SPEED | 當前清理任務的實時清理速度,單位是每秒清理的字節數(估算值)。 |
TTL_CURR_SELECT_SQL_AVG_RT | 當前清理任務執行 |
TTL_CURR_DELETE_SQL_AVG_RT | 當前清理任務執行 |
TTL_CURR_JOB_PERCENT | 當前清理任務的完成百分比。 |
TTL_CURR_CLEANED_PHY_PART_COUNT | 當前清理任務已完成清理的物理分區數。 |
TTL_CURR_TOTAL_PHY_PART_COUNT | 當前清理任務總共需要完成的物理分區數。 |
管理清理任務
您可以通過管理清理任務,使其在合適時間以合適的速度進行數據清理,使清理任務對業務的影響達到最低。
調整可運維時間窗口
PolarDB-X 2.0后臺任務默認的可運維窗口是每天02:00 ~ 05:00,您可以通過如下代碼將可運維的時間窗口調整至每天01:00 ~ 06:00:
set global MAINTENANCE_TIME_START = '01:00';
set global MAINTENANCE_TIME_END = '06:00';
調整清理速度限制
單個存儲節點的清理速度限制默認為1000行每秒,即該節點上所有清理任務速度的總和不超過1000行每秒,實例中存儲節點數越多總清理速度越快。
您可以通過如下代碼調整單個存儲節點的清理速度限制為1萬行每秒:
set global TTL_ENABLE_CLEANUP_ROWS_SPEED_LIMIT=10000
調大清理速度限制會占用更多的CPU和IOPS資源,請您根據存儲節點的實際性能,設置合適的清理速度限制,避免清理任務過度占用存儲節點的CPU和IOPS資源,從而影響業務。
如果該存儲節點的CPU和IOPS資源已經處于滿負荷狀態時,即使通過上述代碼提高清理速度限制也不一定能提升清理速度。
調整清理時間范圍
默認情況下,TTL表的一次清理任務的時間范圍主要是由 TTL_CLEANUP_BOUND_INTERVAL_COUNT
這個參數所控制:
您可以通過如下代碼,調整清理數據的時間范圍:
set global TTL_CLEANUP_BOUND_INTERVAL_COUNT = 6;
TTL_CLEANUP_BOUND_INTERVAL_COUNT
默認值為3,即清理數據的時間范圍是TTL定義中存活時間單位的3倍。執行上述SQL將其調整為6,即清理數據的時間范圍是TTL定義中存活時間單位的6倍,示例如下:
TTL定義的時間單位是天:
`time` EXPIRE AFTER NUM DAY TIMEZONE '+08:00'
,即默認的清理范圍為6天(MinValue≤Time<(MinValue+6 Day))。TTL定義的時間單位是月:
`time` EXPIRE AFTER NUM MONTH TIMEZONE '+08:00'
,即默認的清理范圍為6月(MinValue≤Time<(MinValue+6 Month))。TTL定義的時間單位是年:
`time` EXPIRE AFTER NUM YEAR TIMEZONE '+08:00'
,即默認的清理范圍為6年(MinValue≤Time<(MinValue+6 Year))。
暫停清理任務
通過
SHOW FULL DDL
查看所有清理任務的JOB_ID
:show full ddl\G;
*************************** 1. row *************************** JOB_ID: 1771694362409848832 OBJECT_SCHEMA: ttldb OBJECT_NAME: my_ttl_tbl ENGINE: DAG DDL_TYPE: ALTER_TABLE STATE: RUNNING TOTAL_BACKFILL_PROGRESS: -- CURRENT_PHY_DDL_PROGRESS: 0% PROGRESS: 33% FASTCHECKER_TASK_NUM: 0 FASTCHECKER_TASK_FINISHED: 0 START_TIME: 2024-09-14 15:55:12.991 END_TIME: 2024-09-14 15:55:16.959 ELAPSED_TIME(MS): 3968 PHY_PROCESS: CANCELABLE: true PARENT_JOB_ID: -- RESPONSE_NODE: 10.57.104.154:3067 EXECUTION_NODE: 10.57.104.154:3067 TRACE_ID: 189652a2bc805000 DDL_STMT: alter table my_ttl_tbl cleanup expired data REMARK: -- LEGACY_ENGINE_INFO: -- 1 row in set (0.01 sec)
使用第一步得到的
JOB_ID
,執行如下代碼,即可暫停對應的清理任務:pause ddl 1771694362409848832;
清理任務的DDL JOB可以實時暫?;蚧貪L,但清理任務的回滾僅僅會回滾清理任務本身,并不會回滾已經被清理的數據。更多信息,請參見DDL管理語句。
重啟清理任務
您可以通過執行如下代碼來重啟被暫停的清理任務:
CONTINUE DDL 1771694362409848832;