パーティションテーブルのデータ量が増加すると、既存データ(コールドデータ)が大量のストレージスペースを消費し、ストレージコストが上昇します。このデータへのアクセスを維持しつつコストを削減するには、Data Lifecycle Management (DLM) ポリシーを使用します。このポリシーにより、古いパーティションが自動的に高圧縮の X-Engine フォーマットにアーカイブされます。この機能により、ホットデータとウォームデータをパーティション単位で分離できます。ホットデータはパフォーマンス専有型の InnoDB パーティションに保持され、ウォームデータは X-Engine にアーカイブされるため、ストレージコストを大幅に削減できます。アーカイブされたデータも引き続き DML 書き込みおよびオンライン DDL 変更をサポートし、業務継続性を確保します。
仕組み
パーティションテーブルの自動アーカイブ機能は、テーブルに定義した Data Lifecycle Management (DLM) ポリシーに基づいて動作します。ワークフローは以下のとおりです。
ポリシーの定義:テーブル作成時(
CREATE TABLE)またはテーブル変更時(ALTER TABLE)に DLM ポリシーを定義できます。ポリシーの核となるのは、ユーザーが指定する条件です。たとえば、「パーティション数が N を超えた場合、最も古いパーティションをアーカイブ対象とする」といったルールを設定できます。実行のトリガー:ポリシーはリアルタイムで自動的にトリガーされません。以下のいずれかの方法でアーカイブタスクを実行する必要があります。
手動実行:システムストアドプロシージャを呼び出して、定義済みのすべての DLM ポリシーを即座に実行します。
定期タスク:
EVENTを作成してストアドプロシージャを自動的に呼び出し、毎日深夜など事前に設定したスケジュールに従ってポリシーを実行します。
アーカイブの実行:ポリシーが実行されると、システムはアーカイブ条件を満たすパーティションを特定し、これらのパーティションのストレージエンジンを InnoDB から X-Engine にオンラインで変更して、アーカイブ処理を完了します。
適用範囲
この機能を使用する前に、ご利用のクラスターが以下の条件を満たしていることを確認してください。
Cluster Edition プロダクトシリーズ:
X-Engine ローストアフォーマットへのアーカイブ:MySQL 8.0.2 リビジョン 8.0.1.1.31 以降。
X-Engine 列指向テーブルフォーマットへのアーカイブ:MySQL 8.0.2 リビジョン 8.0.2.2.23 以降。
Multi-master Cluster (Limitless) Edition プロダクトシリーズ:MySQL 8.0.2 リビジョン 8.0.2.0.6 以降。
パーティションアーカイブの設定と実行
このセクションでは、アーカイブポリシーの作成から実行、検証までの全プロセスを説明します。
プロセス概要
DLM アーカイブポリシーの作成:対象のパーティションテーブルに対してアーカイブルールを定義します。
DLM アーカイブポリシーの実行:手動または定期タスクでアーカイブ処理をトリガーします。
アーカイブ状況と結果の確認:パーティションが正常に X-Engine ストレージエンジンに変換されたことを検証します。
ステップ 1:DLM アーカイブポリシーの作成
パーティションテーブルに対してアーカイブルールを定義し、どのタイミングでどのパーティションを X-Engine にアーカイブするかを指定します。新規テーブル作成時にポリシーを追加することも、既存テーブルにポリシーを追加することもできます。
方法 1:新規テーブル作成時にポリシーを定義
CREATE TABLE文の末尾にDLM ADD POLICY句を使用します。以下の例では、salesテーブルを作成します。このテーブルはorder_time列をパーティションキーとして使用し、時間間隔に基づいてパーティションを作成します。また、このテーブルには 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:既存テーブルにポリシーを追加
ALTER TABLE文を使用して、既存のパーティションテーブルに DLM ポリシーを追加します。詳細については、「ALTER TABLE を使用した DLM ポリシーの作成または削除」をご参照ください。ALTER TABLE sales DLM ADD POLICY policy_part2part TIER TO PARTITION ENGINE=XENGINE 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機能を使用できます。これにより、毎日深夜などオフピーク時間帯にポリシーを自動実行し、運用・メンテナンス(O&M)を自動化できます。以下の例では、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:手動による即時実行:一回限りのアーカイブタスクや、問題をトラブルシューティングした後の手動リトライに適しています。
次のストアドプロシージャを直接呼び出して、定義済みのすべての 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ポリシーが属するデータベースおよびテーブル名。
Policy_nameポリシーのカスタム名。
Storage_engineアーカイブ先のストレージエンジン。ここでは
XENGINEです。Tier_partition_numberポリシーで保持する InnoDB パーティション数。
PARTITIONS OVER Nの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の値は、ビジネスシナリオに応じて適切に選択してください。たとえば、注文データの場合、クエリパフォーマンスを確保するために最新 6 ヶ月分のデータを InnoDB パーティションに保持することが考えられます。ログデータの場合、最新 30 日分のみを保持する場合もあります。モニタリングとアラート:
mysql.dlm_progressテーブルのArchive_stageフィールドをモニタリングし、ステータスがARCHIVE_ERRORに変化した場合は、すぐにアラートをトリガーして問題を迅速に解決できるようにしてください。