すべてのプロダクト
Search
ドキュメントセンター

PolarDB:X-Engine フォーマットへのパーティションテーブルのアーカイブ

最終更新日:Feb 11, 2026

パーティションテーブルのデータ量が増加すると、既存データ(コールドデータ)が大量のストレージスペースを消費し、ストレージコストが上昇します。このデータへのアクセスを維持しつつコストを削減するには、Data Lifecycle Management (DLM) ポリシーを使用します。このポリシーにより、古いパーティションが自動的に高圧縮の X-Engine フォーマットにアーカイブされます。この機能により、ホットデータとウォームデータをパーティション単位で分離できます。ホットデータはパフォーマンス専有型の InnoDB パーティションに保持され、ウォームデータは X-Engine にアーカイブされるため、ストレージコストを大幅に削減できます。アーカイブされたデータも引き続き DML 書き込みおよびオンライン DDL 変更をサポートし、業務継続性を確保します。

仕組み

パーティションテーブルの自動アーカイブ機能は、テーブルに定義した Data Lifecycle Management (DLM) ポリシーに基づいて動作します。ワークフローは以下のとおりです。

  1. ポリシーの定義:テーブル作成時(CREATE TABLE)またはテーブル変更時(ALTER TABLE)に DLM ポリシーを定義できます。ポリシーの核となるのは、ユーザーが指定する条件です。たとえば、「パーティション数が N を超えた場合、最も古いパーティションをアーカイブ対象とする」といったルールを設定できます。

  2. 実行のトリガー:ポリシーはリアルタイムで自動的にトリガーされません。以下のいずれかの方法でアーカイブタスクを実行する必要があります。

    • 手動実行:システムストアドプロシージャを呼び出して、定義済みのすべての DLM ポリシーを即座に実行します。

    • 定期タスクEVENT を作成してストアドプロシージャを自動的に呼び出し、毎日深夜など事前に設定したスケジュールに従ってポリシーを実行します。

  3. アーカイブの実行:ポリシーが実行されると、システムはアーカイブ条件を満たすパーティションを特定し、これらのパーティションのストレージエンジンを 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 以降。

パーティションアーカイブの設定と実行

このセクションでは、アーカイブポリシーの作成から実行、検証までの全プロセスを説明します。

プロセス概要

  1. DLM アーカイブポリシーの作成:対象のパーティションテーブルに対してアーカイブルールを定義します。

  2. DLM アーカイブポリシーの実行:手動または定期タスクでアーカイブ処理をトリガーします。

  3. アーカイブ状況と結果の確認:パーティションが正常に 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 を超えると、その制限を超える最も古いパーティションがアーカイブ対象としてマークされます。

テストデータの挿入

  1. 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)
  2. 次のコマンドを実行して、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:アーカイブ状況と結果の確認

アーカイブタスクの進捗をモニターします。タスク完了後、パーティションのストレージエンジンが変更されたことを検証します。

  1. ポリシー定義の確認

    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_schemaTable_name

    ポリシーが属するデータベースおよびテーブル名。

    Policy_name

    ポリシーのカスタム名。

    Storage_engine

    アーカイブ先のストレージエンジン。ここでは XENGINE です。

    Tier_partition_number

    ポリシーで保持する InnoDB パーティション数。PARTITIONS OVER NN に相当します。

  2. 実行進捗の確認

    タスクの状態を追跡するには、ポリシー実行中または実行後に 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_timeEnd_time

    タスクの開始時刻および終了時刻。

    Extra_info

    追加情報。Archive_stageARCHIVE_ERROR の場合、このフィールドに詳細なエラー原因が記録されます。

  3. テーブルスキーマの検証

    アーカイブタスク完了後、SHOW CREATE TABLE コマンドを使用してテーブルスキーマを表示し、古いパーティションの ENGINEXENGINE に変更されたことを確認します。

    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 に変化した場合は、すぐにアラートをトリガーして問題を迅速に解決できるようにしてください。