PolarDB:IBD形式でのアーカイブ

適用可能なバージョン

• リビジョンが 8.0.1.1.51.2 以降のMySQL 8.0.1。

• IBD 形式のアーカイブを使用するには、クォータセンターに移動し、[クォータ ID] で polardb_innodb_oss_enable を検索し、[操作] 列の [申請] をクリックして機能を有効にします。

重要な注意事項

• 読み書きおよびトランザクションの制限 (DML & DDL)

  • DML とトランザクションのサポート：アーカイブテーブルは、INSERT、UPDATE、DELETE などの通常の DML 操作、およびトランザクションをサポートします。

  • DDLの制限：DDL 操作はサポートされません。テーブルを OSS にアーカイブすると、テーブル構造を変更できません。

• アーカイブ中の可用性

  • データアクセスの中断：デフォルトでは、テーブルのアーカイブ中にそのテーブルのデータへアクセスできません。

  • 一時的な回避策：アーカイブ中にテーブルを読み取り可能な状態に保つには、事前に polar_oss_ddl_shared パラメーターを ON に設定します。

• バックアップとデータセキュリティ

  • 標準バックアップの対象外：自動バックアップおよび手動バックアップには、OSS に保存されたデータは含まれません。

  • 復元の制限：OSS 内のデータに対して、データベースまたはテーブルの復元、ならびにポイントインタイムリカバリを実行できません。

• パフォーマンスへの影響と運用上の推奨事項

  • アーカイブ中のリソース消費：コールドデータのアーカイブは、ネットワークおよびストレージ I/O リソースを消費します。この操作は、オフピーク時間帯または非アクティブなクラスターで実施することを推奨します。

  • 高レイテンシのリスク：OSS の I/O レイテンシはブロックストレージの 100 倍以上です。長時間実行される SQL クエリへの影響を評価してください。

  • 大量の書き込み操作：OSS テーブルに対して大量の書き込みや削除を実行する前に、テーブルを先にブロックストレージに戻してください。戻さずに実行すると、次の問題が発生する可能性があります。

    1. キャッシュ汚染：データベースのバッファプールリソースが大量に消費され、空きページを確保できないため、他のテーブルに対する SQL クエリが低速化します。

    2. チェックポイントのブロッキング：多数の OSS ダーティページの永続化が遅延し、チェックポイントの進行がブロックされることで、クラッシュリカバリ時間が長くなります。

    3. クラッシュリカバリの低速化：クラッシュリカバリ中に、OSS テーブルに対するログのリプレイで OSS の読み書きが発生し、クラッシュリカバリがさらに低速化します。

テーブルデータのOSSへのアーカイブ

テーブル内のデータがコールドデータでレイテンシに敏感ではない場合、またはアクセスが集中しており許容できるテールレイテンシでキャッシュできる場合は、次の構文を使用してブロックストレージテーブルを OSS テーブルに変換します。

ALTER TABLE table_name STORAGE_TYPE OSS;

データのブロックストレージへの戻し

ALTER TABLE table_name STORAGE_TYPE NULL;

OSS内の対応ファイルの削除

OSS テーブルを削除するか、ブロックストレージに戻した後も、OSS 内の対応ファイルは自動的に削除されません。データが不要であることを確認した後、次の構文を使用して OSS 内の対応ファイルを削除します。

CALL dbms_oss.delete_table_file('database_name', 'table_name');

OSS でのファイル削除は非同期操作です。システムは、クラスター内のすべてのノードが OSS ファイルに依存しなくなるのを待ってから、ファイルを完全に削除します。トラフィックが多い期間中は、遅延が発生することがあります。コマンドが失敗してエラーメッセージ OSS files are still in use が返された場合は、しばらく待ってから再試行してください。

例

次の例には、テーブルの削除、データベースの削除、および OSS 内のアーカイブ済みファイルの削除が含まれます。操作はテスト用データベースで実行してください。

1. データベースを作成します。

   CREATE DATABASE oss;

2. データベースを使用します。

   USE oss;

3. toss1 テーブルを作成します。

   CREATE TABLE `toss1`(
     `uid` int NOT NULL AUTO_INCREMENT,
     `text_data` text NOT NULL,
     `save_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
     PRIMARY KEY(`uid`)
   ) ENGINE = InnoDB;

4. populate ストアドプロシージャを作成します。

   DELIMITER |
   CREATE PROCEDURE populate(IN `cnt` INT)
   BEGIN
     DECLARE i INT DEFAULT 1;
     WHILE (i <= cnt) DO
       INSERT INTO `toss1` (`text_data`) VALUES (REPEAT("#", 6333));
       SET i = i + 1;
     END WHILE;
   END |
   DELIMITER ;

5. ストアドプロシージャを呼び出して、toss1 テーブルにデータを挿入します。

   CALL populate(5000);

6. データを OSS にアーカイブします。

   ALTER TABLE `toss1` STORAGE_TYPE OSS;

7. toss1 テーブルのデータをクエリします。

   SELECT COUNT(*) FROM `toss1`;

8. OSS の toss1 テーブルをドロップします。

   DROP TABLE `toss1`;

9. OSS データベースを削除します。

   DROP DATABASE oss;

10. データが不要であることを確認した後、OSS 内の対応ファイルを削除してください。

    CALL dbms_oss.delete_table_file('oss', 'toss1');

コールドデータアーカイブに要する時間

コールドデータアーカイブの同時実行スread数は innodb_oss_copy_worker パラメーターで制御され、その値はクラスターの仕様に紐づいています。 次の表に、スレッド数とデータ量ごとのコールドデータアーカイブの所要時間を示します。

適用可能なバージョン

• リビジョンが 8.0.2.2.37 以降のMySQL 8.0.2。ストレージタイプは PSL4 または PSL5 である必要があります。ESSD クラウドディスクはサポートされません。

• コンソールで、設定と管理 > パラメーターに移動し、loose_polar_oss_enable パラメータを有効にします。

• 対象テーブルは file-per-table テーブルスペースと InnoDB ストレージエンジンを使用する必要があります。パーティションテーブルのすべてのパーティションは InnoDB エンジンを使用する必要があります。圧縮テーブルと一般テーブルスペースはサポートされません。

• アーカイブ、クエリ、および戻し操作は、プライマリエンドポイントを介してプライマリノード上で実行し、現在のアカウントが対象テーブルに必要な権限を持っていることを確認してください。

重要な注意事項

• 読み書きとパーティションの挙動 (DML)

  • DML とトランザクションサポート: アーカイブされたテーブルとパーティションは書き込み可能なままです。INSERT、UPDATE、および DELETE 操作とトランザクションがサポートされています。

  • パーティション固有の挙動：

    • クエリ：アーカイブ済みパーティションは、デフォルトで自動的にスキップされます。

    • 更新と削除: UPDATE および DELETE 操作は、アーカイブされたパーティションをスキップしません。これらの操作を実行する前に、影響範囲を確認し、OSS のレイテンシーによる意図しない変更やリクエストのバックログを回避してください。

• スキーマ変更のサポート (DDLルール)

  • DDL機能：列の追加、インデックスの作成、パーティションの調整など、一般的な DDL 操作をサポートします (InnoDB の制限に従います)。

  • アーカイブ状態の継承：アーカイブ状態は、スキーマ変更に応じて自動的に保持または調整されます。ただし、パーティションを再編成した後は、各パーティションのアーカイブ状態を手動で確認することを推奨します。

  • 構文の制限 (結合不可)：

    • アーカイブ操作と復元操作は、個別に実行する必要があります。これらの操作は、単一の ALTER TABLE ステートメントで、他のスキーマ変更 (列の追加やデータ型の変更など) と組み合わせることはできません。

    • アーカイブ操作およびムーブバック操作を実行する場合、ALGORITHM=COPY または ALGORITHM=INSTANT を明示的に指定することはできません。この制限は、アーカイブ操作自体にのみ適用され、アーカイブされたテーブルに対する通常の COPY DDL 操作には影響しません。

• テーブル圧縮とテーブルスペースの制限

  次の操作を実行する前に、関連するテーブルまたはパーティションのデータを OSS からブロックストレージに戻す必要があります。戻し操作によって、テーブルの InnoDB ストレージエンジンは変更されません。

  • テーブル圧縮の有効化: ROW_FORMAT=COMPRESSED とページ圧縮は、アーカイブ状態ではサポートされていません。圧縮を有効にする前に、データを元に戻してください。

  • 一般テーブルスペースへの移動: 一般テーブルスペースでは、複数のテーブルが同じデータファイルを共有できます。 OSS アーカイブでは、各テーブルまたはパーティションが独立した .ibd ファイルを使用する必要があります。 したがって、一般テーブルスペース内のテーブルのアーカイブはサポートされていません。 アーカイブされたテーブルを一般テーブルスペースに移動する前に、データを書き戻してください。

  • テーブル空間のインポートまたは破棄: IMPORT TABLESPACE (テーブル空間ファイルのインポート) または DISCARD TABLESPACE (テーブルが使用するテーブル空間の破棄) を実行する前に、まずデータを戻してください。DISCARD TABLESPACE はデータを戻す操作ではなく、データをブロックストレージに戻すために使用することはできません。

• 透過的データ暗号化 (TDE)

  • TDE は完全にサポートされます。アーカイブおよび戻し操作によって、テーブルの既存の暗号化プロパティは変更されません。

  • 暗号化プロパティを変更するには、デフォルトのアルゴリズムを使用するか、ALGORITHM=COPY を明示的に指定します。ALGORITHM=INPLACE はサポートされていません。

• バックアップ、セキュリティ、および運用上の推奨事項

  • アーカイブはバックアップではありません：DROP および TRUNCATE 操作は、OSS 内のデータを物理的に削除またはクリアします。アーカイブをバックアップの代替として使用しないでください。

  • 同時実行のブロッキングとリソース消費：アーカイブおよび戻し操作は対象テーブルをロックするため、同時の読み書きをブロックし、ネットワークおよびストレージ I/O リソースを消費する場合があります。これらの操作はオフピーク時間帯に実行することを推奨します。

  • 一括変更の推奨：OSS へのアクセスレイテンシはブロックストレージより高いため、一括変更を実行する前に、アーカイブ済みデータをブロックストレージに戻すことを推奨します。

テーブルデータのOSSへのアーカイブ

アーカイブは、アクセス頻度が低く、レイテンシーに敏感ではないデータに適しています。 CREATE TABLE を STORAGE_TYPE と共に指定しても、新しく作成されたテーブルは自動的にアーカイブされません。 最初にテーブルを作成し、その後でアーカイブ操作を実行します：

ALTER TABLE table_name STORAGE_TYPE=HYBRID_OSS;

この構文はパーティションテーブルにも適用されます。ステートメントの実行後、テーブル内のすべてのパーティションがアーカイブされます。

指定パーティションのOSSへのアーカイブ

-- 1つのパーティションをアーカイブします。
ALTER TABLE table_name MODIFY PARTITION p0 STORAGE_TYPE=HYBRID_OSS;

-- 複数のパーティションをアーカイブします。
ALTER TABLE table_name MODIFY PARTITION p0, p1 STORAGE_TYPE=HYBRID_OSS;

テーブル内のデータがすべてコールドデータである場合は、テーブル全体をアーカイブしてください。一部のパーティションにのみコールドデータが含まれる場合は、指定パーティションのみをアーカイブしてください。同一パーティションを複数回アーカイブしないでください。テーブルにサブパーティションが含まれる場合は、サブパーティション名を指定できます。親パーティション名を指定した場合、その親パーティション配下のすべてのサブパーティションがアーカイブされます。

アーカイブ済みデータのクエリ

アーカイブ済みの通常テーブルは、アーカイブ前と同様に直接クエリできます。パーティションテーブルでは、デフォルトでアーカイブされていないパーティションのみがクエリされます。クエリにアーカイブされたパーティションを含めるには、ステートメントに WITH ARCHIVED を追加するか、現在のセッションでアーカイブされたパーティションのフィルタリングを無効にします。

• 単一クエリ: テーブル名の後に WITH ARCHIVED を追加します。これは、この句を含むステートメントにのみ適用され、アーカイブされたデータの 1 回限りのクエリに適しています:

  -- アーカイブされていないパーティションをクエリします。
  SELECT * FROM table_name;
  
  -- アーカイブ済みパーティションを含めてデータをクエリします。
  SELECT * FROM table_name WITH ARCHIVED;

• 現在のセッション：現在のセッションでアーカイブ済みパーティションのフィルタリングを無効にすると、通常のクエリでアーカイブ済みパーティションが含まれます。この方法は現在のセッション全体に適用され、アーカイブ済みデータを継続的にクエリする必要があるシナリオに適しています。

  SET SESSION prune_archived_oss_partitions=OFF;

  prune_archived_oss_partitions パラメーターのデフォルト値は ON です。 これを OFF に設定した後も、クエリは WHERE 句と通常のパーティショニングルールに基づいてデータをフィルターします。 デフォルトの動作に戻すには、このパラメーターを ON に設定します。

アーカイブ状態の確認

SHOW CREATE TABLE table_name;

出力では、テーブルまたはパーティションに STORAGE_TYPE=HYBRID_OSS が含まれている場合、オブジェクトはアーカイブされます。

データのブロックストレージへの戻し

戻し操作ではデータを保持し、対応するテーブルまたはパーティションのアーカイブ状態を解除します。

-- 通常のテーブルを戻します。パーティションテーブルの場合は、アーカイブ済みパーティションがすべて戻されます。
ALTER TABLE table_name STORAGE_TYPE=NULL;

-- 指定パーティションのみを戻します。
ALTER TABLE table_name MODIFY PARTITION p0 STORAGE_TYPE=NULL;

-- アーカイブ済みパーティションをすべて戻します。
ALTER TABLE table_name MODIFY PARTITION ALL STORAGE_TYPE=NULL;

テーブル全体、またはパーティション化されたテーブルのすべてのアーカイブ済みパーティションを復元する必要がある場合は、最初のステートメントを使用します。個々のパーティションのみを復元する必要がある場合は、MODIFY PARTITION を使用してパーティションを指定します。指定されたパーティションは、アーカイブ状態である必要があります。ALL を使用すると、現在アーカイブされているすべてのパーティションが選択されます。

例

次の例では、通常のテーブルとパーティションテーブルに対する操作を示します。例はテスト用データベースで実行してください。例では少量のデータを使用して操作を示しています。実際に削減されるストレージ容量は、テーブルサイズに依存します。