パーティションテーブルのデータ量が増加するにつれて、古い履歴データ (コールドデータ) は大量のストレージ領域を消費し、ストレージコストが増加します。データアクセスを維持しつつストレージコストを削減するために、データライフサイクル管理 (DLM) ポリシーを使用して、古いパーティションを高圧縮エンジン (X-Engine) 形式に自動的にアーカイブできます。この機能により、パーティションレベルでホットデータとウォームデータを分離できます。ホットデータは高性能な InnoDB パーティションに残り、X-Engine にアーカイブされたウォームデータはストレージコストを大幅に削減し、引き続き DML の書き込みとオンライン DDL の変更をサポートします。
仕組み
自動パーティションアーカイブ機能は、テーブルに定義するデータライフサイクル管理 (DLM) ポリシーを使用します。仕組みは次のとおりです。
ポリシーの定義: DLM ポリシーは、
CREATE TABLEでテーブルを作成するとき、またはALTER TABLEでテーブルを変更するときに定義できます。ポリシーの中核は、いつアーカイブするかを指定する条件です。たとえば、パーティションの数がしきい値を超えた場合、最も古いパーティションがアーカイブ対象としてマークされます。実行のトリガー:ポリシーは自動的にはトリガーされません。次の 2 つの方法のいずれかでアーカイブタスクを開始する必要があります。
手動実行:システムのストアドプロシージャを呼び出して、定義されているすべての DLM ポリシーを即座に実行します。
定期実行:
EVENTを作成し、オフピーク時に毎日など、事前定義されたスケジュールでストアドプロシージャを自動的に呼び出してポリシーを実行します。
アーカイブの実行:ポリシーが実行されると、システムはアーカイブ条件を満たすテーブルパーティションを特定し、そのストレージエンジンを InnoDB から X-Engine にオンラインで変更してアーカイブを完了します。
前提条件
この機能を使用する前に、クラスターが次の要件を満たしていることを確認してください。
エディション:Cluster Edition。
カーネルバージョン:
X-Engine の行ベース形式にアーカイブする場合:
MySQL 8.0.2、リビジョンバージョン 8.0.2.2.34.1 以降。
X-Engine の カラムナテーブル形式にアーカイブする場合:
MySQL 8.0.2、リビジョンバージョン 8.0.2.2.34.1 以降。
パーティションアーカイブの設定と実行
このセクションでは、アーカイブポリシーの作成、実行、および検証について説明します。
プロセスの概要
DLM アーカイブポリシーの作成:対象のパーティションテーブルにアーカイブ規則を定義します。
DLM アーカイブポリシーの実行:手動またはスケジュールされたタスクでアーカイブプロセスをトリガーします。
アーカイブステータスと結果の表示:パーティションが正常に X-Engine に変換されたことを確認します。
ステップ 1: DLM アーカイブポリシーの作成
パーティションテーブルの作成時にアーカイブポリシーを定義するか、既存のテーブルにポリシーを追加できます。
方法 1: 新しいテーブルの作成時にポリシーを定義する
CREATE TABLEステートメントの最後にDLM ADD POLICY句を使用します。 次の例では、order_time列をパーティショニングキーとして使用するsalesテーブルを作成します。 このテーブルには、INTERVAL ポリシーと DLM ポリシーの 2 つのポリシーがあります。INTERVAL ポリシー:挿入されたデータが既存のパーティション範囲外にある場合、1 年間隔で新しいパーティションを自動的に作成します。
DLM ポリシー:
policy_part2partという名前のポリシーです。このポリシーでは、パーティションの総数が 3 を超えると、最も古いパーティションが X-Engine にアーカイブされるようにマークされます。
CREATE TABLE `sales` ( `id` int DEFAULT NULL, `name` varchar(20) DEFAULT NULL, `order_time` datetime NOT NULL, primary key (order_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 PARTITION BY RANGE COLUMNS(order_time) INTERVAL(YEAR, 1) (PARTITION p20200101000000 VALUES LESS THAN ('2020-01-01 00:00:00') ENGINE = InnoDB, PARTITION p20210101000000 VALUES LESS THAN ('2021-01-01 00:00:00') ENGINE = InnoDB, PARTITION p20220101000000 VALUES LESS THAN ('2022-01-01 00:00:00') ENGINE = InnoDB) DLM ADD POLICY policy_part2part TIER TO PARTITION ENGINE=XENGINE READ WRITE ON (PARTITIONS OVER 3);方法 2: 既存のテーブルにポリシーを追加する
既存のパーティション化されたテーブルに DLM ポリシーを追加するには、
ALTER TABLEステートメントを使用します。詳細については、「ALTER TABLE で DLM ポリシーを作成または削除する」をご参照ください。ALTER TABLE sales DLM ADD POLICY policy_part2part TIER TO PARTITION ENGINE=XENGINE READ WRITE ON (PARTITIONS OVER 3);構文の説明:
ON (PARTITIONS OVER N)はポリシーの中核です。ここで、Nは InnoDB エンジンで保持する最新のパーティション数です。パーティションの総数がNを超えると、この数を超えた最も古いパーティションはアーカイブ対象としてマークされます。
テストデータの挿入
proc_batch_insertストアドプロシージャを使用してsalesパーティションテーブルにテストデータを挿入すると、INTERVAL ポリシーがトリガーされ、新しいパーティションが自動的に作成されます。DROP PROCEDURE IF EXISTS proc_batch_insert; delimiter $$ CREATE PROCEDURE proc_batch_insert(IN begin INT, IN end INT, IN name VARCHAR(20)) BEGIN SET @insert_stmt = concat('INSERT INTO ', name, ' VALUES(? , ?, ?);'); PREPARE stmt from @insert_stmt; WHILE begin <= end DO SET @ID1 = begin; SET @NAME = CONCAT(begin+begin*281313, '@stiven'); SET @TIME = from_days(begin + 737600); EXECUTE stmt using @ID1, @NAME, @TIME; SET begin = begin + 1; END WHILE; END; $$ delimiter ; CALL proc_batch_insert(1, 3000, 'sales');次の結果は、データが正常に挿入されたことを示します。
Query OK, 1 row affected (0.50 sec)次のコマンドを実行して、
salesテーブル構造を表示します。SHOW CREATE TABLE sales \G出力にはテーブル構造が表示され、現在すべてのパーティションが InnoDB を使用していることがわかります。
mysql> SHOW CREATE TABLE sales \G *************************** 1. row *************************** Table: sales Create Table: CREATE TABLE `sales` ( `id` int(11) DEFAULT NULL, `name` varchar(20) DEFAULT NULL, `order_time` datetime NOT NULL, PRIMARY KEY (`order_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci /*!50500 PARTITION BY RANGE COLUMNS(order_time) */ /*!99990 800020200 INTERVAL(YEAR, 1) */ /*!50500 (PARTITION p20200101000000 VALUES LESS THAN ('2020-01-01 00:00:00') ENGINE = InnoDB, PARTITION p20210101000000 VALUES LESS THAN ('2021-01-01 00:00:00') ENGINE = InnoDB, PARTITION p20220101000000 VALUES LESS THAN ('2022-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20230101000000 VALUES LESS THAN ('2023-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20240101000000 VALUES LESS THAN ('2024-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20250101000000 VALUES LESS THAN ('2025-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20260101000000 VALUES LESS THAN ('2026-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20270101000000 VALUES LESS THAN ('2027-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20280101000000 VALUES LESS THAN ('2028-01-01 00:00:00') ENGINE = InnoDB) */
ステップ 2: DLM アーカイブポリシーの実行
定義されたアーカイブポリシーをトリガーして、パーティションのエンジン変換プロセスを開始します。ビジネスニーズに応じて、手動で実行するか、スケジュールされたタスクを設定するかを選択できます。
方法 1: 定期実行 (推奨): 定期的なデータアーカイブが必要な本番環境では、MySQL の
EVENT機能を使用して、早朝などのオフピーク時にタスクを自動実行することをお勧めします。 このアプローチにより、タスクが自動化されます。次の例では、2026-02-01 に開始し、毎日 01:00 にすべての DLM ポリシーを実行するイベントを作成します。
CREATE EVENT dlm_system_base_event ON SCHEDULE EVERY 1 DAY STARTS '2026-02-01 01:00:00' do CALL dbms_dlm.execute_all_dlm_policies();方法 2: 手動実行:この方法は、1 回限りのアーカイブタスクや、トラブルシューティング後にタスクを手動で再試行する場合に適しています。
次のストアドプロシージャを呼び出して、定義されているすべての DLM ポリシーを即時にトリガーします。
CALL dbms_dlm.execute_all_dlm_policies();
ステップ 3: アーカイブステータスと結果の表示
アーカイブタスクの進捗を監視します。タスクが完了したら、パーティションのエンジンが変更されたことを確認します。
ポリシー定義の表示
mysql.dlm_policiesシステムテーブルにクエリを実行して、ポリシーが作成されたことを確認します。SELECT * FROM mysql.dlm_policies WHERE Table_schema = 'your_database' AND Table_name = 'sales'\G次の結果が返されます。
*************************** 1. row *************************** Id: 1 Table_schema: your_database Table_name: sales Policy_name: policy_part2part Policy_type: PARTITION Archive_type: PARTITION COUNT Storage_mode: READ WRITE Storage_engine: XENGINE Storage_media: DISK Storage_schema_name: NULL Storage_table_name: NULL Data_compressed: ON Compressed_algorithm: Zstandard Enabled: ENABLED Priority_number: 200 Tier_partition_number: 3 Tier_condition: NULL Extra_info: {"oss_file_filter": "order_time"} Comment: NULL主要なフィールドの説明:
フィールド
説明
Table_schema,Table_nameポリシーが属するデータベースとテーブル。
ポリシー名ポリシーのカスタム名。
Storage_engineアーカイブパーティションの対象ストレージエンジンです。この例では、
XENGINEです。Tier_partition_numberこのポリシーは、保持する InnoDB パーティションの数を定義します。これは
Nであり、PARTITIONS OVER Nで使用されます。実行進捗の表示
ポリシーの実行中または実行後に、
mysql.dlm_progressシステムテーブルを照会して、タスクのステータスを追跡できます。SELECT * FROM mysql.dlm_progress WHERE Table_schema = 'your_database' AND Table_name = 'sales' ORDER BY Id DESC LIMIT 1\G次の結果が返されます。
*************************** 1. row *************************** Id: 1 Table_schema: your_database Table_name: sales Policy_name: policy_part2part Policy_type: PARTITION Archive_option: PARTITIONS OVER 3 Storage_engine: XENGINE Storage_media: DISK Data_compressed: ON Compressed_algorithm: Zstandard Archive_partitions: p20200101000000, p20210101000000, p20220101000000, _p20230101000000, _p20240101000000, _p20250101000000 Archive_stage: ARCHIVE_COMPLETE Archive_percentage: 100 Archived_file_info: null Start_time: 2026-02-06 10:50:00 End_time: 2026-02-06 10:50:00 Extra_info: null主要なフィールドの説明:
フィールド
説明
Archive_partitionsこのタスクでアーカイブされたパーティション。
Archive_stageアーカイブタスクの現在のステータスです。
ARCHIVE_COMPLETEは成功、ARCHIVE_ERRORは失敗を示します。Archive_percentageタスクの完了率。
Start_time,End_timeタスクの開始時刻と終了時刻。
Extra_info補足情報。
Archive_stageがARCHIVE_ERRORの場合、このフィールドにはエラー詳細が含まれます。テーブル構造の検証
アーカイブタスクが完了したら、
SHOW CREATE TABLEコマンドを使用してテーブル構造を表示し、アーカイブされたパーティションのENGINEがXENGINEに変更されたことを確認します。SHOW CREATE TABLE sales\G次の結果が返されます。
*************************** 1. row *************************** Table: sales Create Table: CREATE TABLE `sales` ( `id` int(11) DEFAULT NULL, `name` varchar(20) DEFAULT NULL, `order_time` datetime NOT NULL, PRIMARY KEY (`order_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci /*!99990 800020216 PARTITION BY RANGE COLUMNS(order_time) */ /*!99990 800020200 INTERVAL(YEAR, 1) */ /*!99990 800020216 (PARTITION p20200101000000 VALUES LESS THAN ('2020-01-01 00:00:00') ENGINE = XENGINE, PARTITION p20210101000000 VALUES LESS THAN ('2021-01-01 00:00:00') ENGINE = XENGINE, PARTITION p20220101000000 VALUES LESS THAN ('2022-01-01 00:00:00') ENGINE = XENGINE, PARTITION _p20230101000000 VALUES LESS THAN ('2023-01-01 00:00:00') ENGINE = XENGINE, PARTITION _p20240101000000 VALUES LESS THAN ('2024-01-01 00:00:00') ENGINE = XENGINE, PARTITION _p20250101000000 VALUES LESS THAN ('2025-01-01 00:00:00') ENGINE = XENGINE, PARTITION _p20260101000000 VALUES LESS THAN ('2026-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20270101000000 VALUES LESS THAN ('2027-01-01 00:00:00') ENGINE = InnoDB, PARTITION _p20280101000000 VALUES LESS THAN ('2028-01-01 00:00:00') ENGINE = InnoDB) */
本番環境での考慮事項
ポリシー設計: ビジネスシナリオに基づいて、
PARTITIONS OVER Nの適切なN値を選択します。 たとえば、注文データの場合、クエリパフォーマンスを確保するために、InnoDB パーティションに直近 6 か月分のデータを保持します。 ログデータの場合、直近 30 日間のデータのみを保持するだけで十分な場合があります。監視とアラート:
mysql.dlm_progressテーブルのArchive_stageフィールドを監視します。ステータスがARCHIVE_ERRORの場合、迅速な対応ができるように、直ちにアラートをトリガーします。