すべてのプロダクト
Search

このプロダクト

    PolarDB:コールドデータアーカイブ

    ドキュメントセンター

    PolarDB:コールドデータアーカイブ

    最終更新日:Sep 03, 2026

    コールドデータをアーカイブする前に、ご希望のアーカイブフォーマットを確認し、お使いのクラスターが要件を満たしていることも確認してください。詳細については、アーカイブフォーマットの比較および前提条件をご参照ください。

    適用範囲

    • CSV フォーマットへのアーカイブ

      • クラスターエディションは Cluster Edition：

        • 標準テーブルのアーカイブ：

          • MySQL 8.0.1、リビジョン 8.0.1.1.47 以降。

          • MySQL 8.0.2、リビジョン 8.0.2.2.10 以降。

        • パーティションテーブルのアーカイブ：

          • MySQL 8.0.2、リビジョン 8.0.2.2.34.1 以降。

      • クラスター版が マルチマスタークラスター (Limitless) Edition の場合：

        • MySQL 8.0.1、リビジョン 8.0.1.0.13 以降。

    • ORC フォーマットへのアーカイブ

      • クラスター版は Cluster Edition：

        • 標準テーブルのアーカイブ：MySQL 8.0.2、リビジョン 8.0.2.2.30 以降。

        • パーティションテーブルのアーカイブ：MySQL 8.0.2、リビジョン 8.0.2.2.34.1 以降。

      • クラスター版が マルチマスタークラスター (Limitless) Edition の場合：MySQL 8.0.2、リビジョン 8.0.2.2.30 以降。

    • X-Engine フォーマットへのアーカイブ

      • 標準テーブルのアーカイブ：

        • MySQL 8.0.1、リビジョン 8.0.1.1.31 以降。

        • MySQL 8.0.2、リビジョン 8.0.2.2.12 以降。

      • パーティションテーブルのアーカイブ：MySQL 8.0.2、リビジョン 8.0.2.2.12 以降。

      • X-Engine 列ストアテーブルへのアーカイブ：MySQL 8.0.2、リビジョン 8.0.2.2.34.1 以降。

    パラメーター

    コールドデータアーカイブ機能を使用する場合、ビジネス要件に基づいて、クラスターのパラメーター ページで以下のパラメーターを設定できます。

    パラメーター

    レベル

    説明

    loose_polar_dlm_storage_mode

    グローバル

    データライフサイクル管理 (DLM) によるコールドデータの自動アーカイブを有効にするかどうかを制御します。有効な値：

    • OFF (デフォルト)：DLM ストレージが無効になります。スケジューラは起動せず、アーカイブは実行されません。

    • RO (非推奨)：DLM ストレージが読み取り専用になります。アーカイブ済みのコールドデータパーティションはクエリできますが、新規のアーカイブ書き込みは実行されません。この値は本番環境ではほとんど使用されません。

    • RW (推奨)：DLM ストレージが読み取り/書き込み可能になります。スケジューラが起動し、DLM ポリシーに基づく自動アーカイブをサポートします。また、アーカイブ済みデータもクエリできます。

    説明

    • このパラメーターは、リビジョンバージョンが 8.0.2.2.34.1 以降の MySQL 8.0.2 クラスターにのみ適用されます。

    • コールドデータアーカイブを有効化すると、システムはこのパラメーターを自動的に RW に設定します。手動で変更する必要はありません。

    • X-Engine の高圧縮エンジンのみを使用してパーティション表をアーカイブする場合 (OSS コールドデータアーカイブを使用しない場合)、DLM スケジューリングを有効化するために、このパラメーターを手動で RW に設定する必要があります。

    loose_polar_allow_create_hybrid_partition

    グローバル

    InnoDB 以外のストレージエンジンを使用するパーティションを含むパーティション表の作成またはアーカイブを許可するかどうかを制御します。有効な値：

    • OFF (デフォルト)：InnoDB 以外のストレージエンジンを使用するパーティションを含むパーティション表の作成は許可されません。すべてのパーティションで InnoDB ストレージエンジンを使用する必要があります。

    • ON (推奨)：InnoDB 以外のストレージエンジンを使用するパーティションを含むパーティション表の作成が許可されます。パーティション単位で OSS (CSV/ORC) または X-Engine エンジンを指定できます。

    説明

    • このパラメーターは、リビジョンバージョンが 8.0.2.2.34.1 以降の MySQL 8.0.2 クラスターにのみ適用されます。

    • コールドデータアーカイブを有効化すると、バージョンによっては、システムがこのパラメーターを自動的に ON に設定する場合があります。

    loose_use_oss_meta

    グローバル / セッション

    OSS テーブルで OSS メタデータ (meta) 管理を有効にするかどうかを制御します。loose_csv_oss_file_filter パラメーターは、このパラメーターに依存します。有効な値：

    • ON：OSS メタデータ管理が有効になります。OSS テーブルの作成またはアーカイブ時に meta 情報が書き込まれます。その後、メタデータを読み取ってファイルリストを取得します。これにより、loose_csv_oss_file_filter のフィルタリング機能を使用できます。

    • OFF：OSS メタデータ管理が無効になります。meta 情報は書き込まれません。OSS ファイルを直接リストしてメタデータを取得するため、loose_csv_oss_file_filter はサポートされません。

    loose_csv_oss_file_filter

    グローバル / セッション

    OSS テーブルのクエリ時に、ファイルレベルのフィルタリング (File Filter) を有効にするかどうかを制御します。この機能は min/max 統計とブルームフィルターを使用して不要なデータファイルをスキップし、スキャンする OSS データ量を削減します。この機能を使用するには、loose_use_oss_meta パラメーターを有効にする必要があります。有効な値：

    • OFF：ファイルフィルタリングが無効になります。クエリ実行時に、OSS テーブル内のすべてのデータファイルがスキャンされます。

    • ON (推奨)：ファイルフィルタリングが有効になります。クエリ実行時に、loose_csv_oss_file_filter を WHERE 条件と併用することで、クエリパフォーマンスが向上します。

    dlm_prune_archiving_oss_partitions

    グローバル / セッション

    データライフサイクル管理 (DLM) による、DML 操作時の自動パーティションプルーニングを有効にするかどうかを制御します。DML 操作 (UPDATE/DELETE) の実行時に、システムは OSS (ORC/CSV) へアーカイブ中のパーティションと、すでに OSS にアーカイブ済みのパーティションを自動的にプルーニングします。これにより、アーカイブによる DML 操作のブロックを防ぎ、DML と DDL の競合を解消します。有効な値：

    • ON (デフォルト、推奨)：DML 操作 (UPDATE/DELETE) により、OSS へのアーカイブ中のパーティションが自動的にプルーニングされます。

    • OFF：DML 操作では、OSS へのアーカイブ中のパーティションは自動的にプルーニングされません。

    hybrid_partition_query_mix_engine_enabled

    グローバル / セッション

    SELECT クエリの実行時に、コールドデータである OSS (ORC/CSV) パーティションを自動的にプルーニングするかどうかを制御します。このパラメーターはデフォルトで OFF に設定されており、その場合にプルーニングが有効になります。有効な値：

    • OFF (デフォルト、推奨)：クエリ実行時に、OSS パーティションが自動的にプルーニングされます。

    • ON (非推奨)：クエリ実行時に、OSS パーティションは自動的にプルーニングされません。

    コールドデータのアーカイブ

    コールドデータのクエリ

    • 通常のテーブル

      選択したアーカイブフォーマットにかかわらず、テーブルへのアクセス方法を変更することなく、アーカイブ済みデータをクエリできます。

    • パーティションテーブル

      • OSS 外部テーブルへのアーカイブ：このデータをクエリするには、別のアクセス方法が必要です。指定されたアーカイブテーブルをクエリする必要があります。詳細については、「パーティションを OSS 外部テーブルにアーカイブ」をご参照ください。

      • パーティションのインプレースアーカイブ：アーカイブ後、テーブルはハイブリッドパーティションテーブルになります。詳細については、「ハイブリッドパーティションのクエリ」をご参照ください。

        異なるストレージエンジン上のパーティションは、3 つの方法でクエリできます：

        • hybrid_partition_query_mix_engine_enabled パラメーターを ON に設定します。 クエリは、InnoDB、X-Engine、および OSS 上のパーティションからデータを返します。 例：

          -- t1 はハイブリッドパーティションテーブルです。
SELECT * FROM t1;

        • hybrid_partition_query_mix_engine_enabled パラメーターを OFF に設定します。 クエリは、InnoDB および X-Engine パーティションからのみデータを返します。 例：

          -- t1 はハイブリッドパーティションテーブルです。
SELECT * FROM t1;

        • 名前で特定のパーティションをクエリします。 これにより、ストレージエンジンに関係なく、指定されたパーティションからデータが取得されます。 例：

          -- t1 はハイブリッドパーティションテーブルで、p1 はクエリするパーティションの名前です。
SELECT * FROM t1 partition (p1);
    説明

    システムは、テーブルごとにアーカイブ済みコールドデータをマルチファイル形式で格納します。クエリパフォーマンスを最適化するには、パラレルクエリを使用してください。詳細については、「コールドデータのパラレルクエリ」をご参照ください。

    コールドデータの変更

    To infrequently modify cold data stored on Object Storage Service (OSS), use the ALTER statement to move it back to the PolarDB storage space for modification. The system then automatically deletes the data from OSS. After you modify the data, you can archive the table data to OSS again.

    Common tables

    Syntax

    ALTER TABLE table_name ENGINE[=]engine_name;

    Parameters

    Parameter

    Description

    table_name

    The name of the OSS table to move back to the PolarDB storage space.

    engine_name

    The storage engine to use after the table is moved back.

    Usage notes

    OSS tables are read-only. You cannot modify them by usingINSERT,UPDATE, orDELETE statements. To modify archived cold data, you must convert the OSS table into a read-write table, such as an InnoDB table. Attempting to modify a read-only OSS table returns the following error:

    1036 - Table 't' is read only

    Example

    Move the OSS table t from the oss_test database back to the PolarDB storage space.

    ALTER TABLE `oss_test`.`t` ENGINE = InnoDB;

    Modify the data in the InnoDB tablet. After the modification is complete, archive the tablet from the InnoDB engine back to OSS. Example:

    ALTER TABLE t ENGINE = CSV CONNECTION = 'default_oss_server';

    or

    ALTER TABLE t ENGINE = CSV STORAGE OSS;

    Partitioned tables

    説明

    To modify cold data in a partitioned table, your PolarDB for MySQL cluster must be version 8.0.2 with revision version 8.0.2.2.34 or later.

    Syntax

    ALTER TABLE table_name REORGANIZE PARTITION part_name INTO (partition_definition);

    Parameters

    Parameter

    Description

    table_name

    The name of the OSS table to move back.

    part_name

    The name of the partition to move back.

    partition_definition

    This must be consistent with the partition_definition of the partition that you want to move back.

    Example

    Move the data in partition p1 of the partitioned table t, which is archived on OSS, back to the PolarDB storage space.

    ALTER TABLE t REORGANIZE PARTITION p1 INTO(PARTITION p1 values less than(100));

    コールドデータの削除

    説明

    • この機能は、次のバージョンを実行する PolarDB for MySQL クラスターでのみサポートされています：

      • バージョン 8.0.1、マイナーバージョンは 8.0.1.1.42 以降である必要があります。

      • バージョン 8.0.2、マイナーバージョンは 8.0.2.2.23 以降である必要があります。

    • ご利用のクラスターのマイナーバージョンが上記の要件を満たしていない場合、OSS 上の対応するファイルを削除することはできません。クラスターのマイナーバージョンをアップグレードしてください。詳細については、「マイナーバージョン管理」をご参照ください。

    OSS 上のテーブルを削除した後、または PolarDB のストレージ領域に再インポートした後も、OSS 上のファイルは自動的に削除されません。データが不要になったことを確認した後、次の手順で OSS 上の該当ファイルを削除してください。詳細については、「OSS 上の対応するファイルを削除」をご参照ください。

    • 通常のテーブルと OSS 外部テーブル

      DROP TABLE を使用して、アーカイブされたテーブルを削除します。次に、CALL dbms_oss.delete_table_file('database_name', 'table_name'); コマンドを実行して、OSS 上の該当ファイルを削除します。

    • パーティションテーブル

      CALL dbms_oss.delete_table_file('database_name', 'table_name'); コマンドを実行して、OSS 上の該当ファイルを削除します。

    OSS 上の該当ファイルを削除する操作は非同期で実行されます。クラスター内のすべてのノードがこれらのファイルに依存しなくなった後にのみ、ファイルは完全に削除されます。このプロセスは、トラフィックが多い場合に遅延することがあります。

    FORCE STORAGE OSS オプション

    説明

    OSS ファイルを強制的に削除する FORCE STORAGE OSS オプションは、マイナーバージョンが 8.0.2.2.29 以降の PolarDB for MySQL 8.0.2 クラスターでのみサポートされます。

    • 通常のテーブルと OSS 外部テーブル

      DROP TABLE table_name [FORCE STORAGE OSS];
      説明

      DROP TABLE コマンドの FORCE STORAGE OSS オプションは、テーブル構造を削除する際に、関連付けられた OSS ストレージファイルを自動的に削除するワンクリッククリーンアップ機能です。

    • パーティションテーブル

      ALTER TABLE table_name DROP PARTITION part_name [FORCE STORAGE OSS];
      説明

      ALTER TABLE ステートメントの DROP PARTITION 句は、FORCE STORAGE OSS オプションと併用すると、パーティションテーブルのメタデータと該当する OSS ストレージファイルを同期的に削除できます。

    • CHANGE PARTITION ENGINE

        ALTER TABLE table_name CHANGE PARTITION part_name ENGINE = CSV|ORC [FORCE STORAGE OSS]
      説明

      CHANGE PARTITION ENGINE のコールドデータアーカイブ機能は、同名のファイルを自動的に置き換える強制上書きメカニズムです。

    アーカイブフォーマットの比較

    コールドデータをアーカイブする際、以下の比較に基づいて適切なフォーマットを評価し、選択できます。

    説明

    • 標準テーブル、OSS 外部テーブル、パーティションテーブルのアーカイブには特定の制限があります。ビジネスへの影響を避けるため、アーカイブする前にこれらの制限事項を確認してください。

    • コールドデータがアーカイブされると、データはご利用の OSS ではなく、システムが提供するデフォルトの Object Storage Service (OSS) バケットに保存されます。現在、アーカイブされたデータのリストは PolarDB コンソールでのみ表示できます。

    • パーティションテーブルのアーカイブ方法：

      • パーティションテーブルのアーカイブ：パーティションをその場でアーカイブします。データは元のテーブルに残りますが、そのパーティションの記憶媒体が PolarDB (ホットストレージ) から OSS (コールドストレージ) に変更されます。テーブルは、ホットパーティションとコールドパーティションの両方を含むハイブリッドパーティションテーブルになります。

      • パーティションの OSS 外部テーブルへのアーカイブ：パーティションのデータをテーブルから移動し、新しい独立した OSS 外部テーブルに保存します。元のパーティションはソーステーブルから削除されます。

    比較項目

    CSV

    ORC

    X-Engine

    オープンソースフォーマット

    はい

    はい

    いいえ

    アーカイブ方法

    手動アーカイブ：

    アーカイブ速度

    高速

    説明

    シングルスレッドのアーカイブのみサポートされています。

    低速

    説明

    シングルスレッドのアーカイブのみサポートされています。

    高速

    説明

    データは PolarStore ストレージにアーカイブされます。

    クエリ速度

    • 比較的低速。インデックスがなく、シーケンシャルクエリを使用する場合、クエリパフォーマンスは InnoDB ストレージエンジンの約 1/5 から 1/10 です。

    • 行ストアノードでは ORC フォーマットよりも高速です。

    説明

    シングルスレッドおよびマルチスレッドの読み取りがサポートされています。

    • 比較的低速。インデックスがなく、シーケンシャルクエリを使用する場合、クエリパフォーマンスは InnoDB ストレージエンジンの約 1/5 から 1/10 です。

    • 専用の列ストアノードを介した AP クエリに適しています。

    説明

    シングルスレッドの読み取りのみサポートされています。

    • 高速。データは PolarStore ストレージに保存されるため、クエリ速度は OSS コールドデータよりも大幅に高速ですが、InnoDB よりも約 30% 低速です。

    • 行ストアテーブルは TP クエリに適しており、列ストアテーブルは列ストアノードでの AP クエリに適しています。

    トランザクションサポート

    いいえ

    いいえ

    はい

    インデックス機能

    いいえ

    いいえ

    はい

    アーカイブ済みデータの変更方法

    OSS 内のアーカイブ済みテーブルは読み取り専用です。データを変更するには、OSS から PolarDB ストレージにデータをインポートして戻す必要があります。

    アーカイブ済みテーブルは DML 操作をサポートしています。

    ストレージ領域の使用量

    インデックスのない InnoDB テーブルと同じです。

    同じデータ量の場合、ORC は CSV が使用するストレージ領域の約 45% を使用します。

    データを InnoDB サイズの 10%～50% に圧縮します。実際の圧縮率はデータの特性によって異なります。

    バックアップとリカバリ

    サポートされていません。

    説明

    • Object Storage Service (OSS) は、99.9999999999% (トゥエルブナイン) のデータの耐久性と 99.995% のデータの可用性を提供し、コールドデータ損失のリスクを事実上排除します。

    • PolarDB のバックアップを実行する際、OSS 内のアーカイブされたコールドデータはバックアップされません。したがって、データベースとテーブルの復元、バックアップベースのリカバリ、およびポイントインタイムリカバリはサポートされていません。

    サポートされています。

    アーカイブ後の影響

    アーカイブ後、アクセス方法を変更せずにアーカイブされたデータをクエリできます。