このトピックでは、PolarDB for MySQL で期限切れのデータを自動的に削除する Time to Live(TTL)機能について説明します。
バージョンの制限
PolarDB for MySQL は、次のデータベースエンジンバージョンをサポートしています。
MySQL 8.0.1 (リビジョンバージョン 8.0.1.1.49.2 以降)
MySQL 8.0.2 (リビジョンバージョン 8.0.2.2.29.2 以降)
詳細については、「カーネルバージョンの説明」をご参照ください。
注意事項
一時テーブル(ローカル一時テーブルとグローバル一時テーブルを含む)に TTL プロパティを設定することはできません。
TTL プロパティを持つテーブルは、インメモリ列インデックス(IMCI)、マルチマスタークラスター(Limitless)エディション、グローバルセカンダリインデックス(GSI)、またはパーティションテーブルなどの機能をサポートしていません。
TTL プロパティを持つテーブルは、外部キー制約のプライマリテーブルとして他のテーブルから参照することはできません。
TTL プロパティを持つテーブルには、トリガーを含めることはできません。
期限切れのデータはすぐに削除されない場合があります。期限切れデータの削除時間は、バックグラウンドクリーンアップタスクのスケジュールサイクルによって異なります。
バックアップからデータベースまたはテーブルを復元する場合、
loose_innodb_enable_ttl_purgeパラメーターを OFF に設定して、期限切れデータのパージを無効にする必要があります。これは、復元後にすべてのデータがすでに期限切れになっている可能性があるためです。TTL プロパティを持つ列は、TIMESTAMP 型である必要があります。
TTL 機能によって削除されたデータは、バイナリログレコードを生成しません。したがって、データ同期にバイナリログを使用し、ソースデータベースのテーブルで TTL 機能が有効になっている場合、セカンダリデータベースでキー値の競合が発生する可能性があります。
構文
CREATE TABLE 文または ALTER TABLE 文を使用して、テーブルの TTL 機能を設定できます。
TTL プロパティを持つテーブルを作成する
次のいずれかの方法を使用して、TTL プロパティを持つテーブルを作成できます。
t1 という名前のテーブルが作成されます。ここで、created_at は、データの作成時刻を格納する Time to Live(TTL)列です。created_at 列に基づいて TTL 値を設定して、データがいつ削除されるかを決定できます。
created_atの Time to Live を 100 秒に設定します。CREATE TABLE `t1` ( `a` INT PRIMARY KEY, `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_created_at (`created_at`) )ENGINE=InnoDB TTL='created_at@100';説明TTL='created_at@100'は、テーブルの行の Time to Live を 100 秒に設定します。この期間より古い行は期限切れとしてマークされ、後で削除されます。created_atの Time to Live を 3 時間に設定します。CREATE TABLE `t1` ( `a` INT PRIMARY KEY, `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_created_at (`created_at`) )ENGINE=InnoDB TTL='created_at' + INTERVAL 3 HOUR;説明式
TTL ='created_at'+ INTERVAL 3 HOURは、テーブルの行の Time to Live を 3 時間に設定します。期限切れのデータは自動的に削除されます。TTL 設定は、YEAR、QUARTER、MONTH、WEEK、DAY、HOUR、MINUTE、SECOND などの複数の時間単位をサポートしています。この柔軟性により、要件に基づいて効率的なデータ管理に適した時間単位を選択できます。
テーブルの TTL プロパティを変更する
次のいずれかの方法を使用して、テーブルの TTL プロパティを変更できます。
次の例では、t1 テーブルの created_at 列の Time to Live を変更します。
created_atの Time to Live を 10,000 秒に変更します。ALTER TABLE `t1` TTL='created_at@10000';説明この設定により、
created_atフィールドの値に基づいて、データの作成時刻から 10,000 秒後にデータが自動的に削除されます。created_atの Time to Live を 3 日に変更します。ALTER TABLE `t1` TTL='created_at' + INTERVAL 3 DAY;説明これは、データの有効期限を
created_at列の値から 3 日後に設定します。3 日より古いデータは自動的に削除されます。
テーブルの TTL プロパティをクリアする
ALTER TABLE t1 TTL = '';テーブルの TTL プロパティをクエリする
SHOW CREATE TABLE `t1` FULL;
CREATE TABLE `t1` (
`a` INT PRIMARY KEY,
`created_at` TIMESTAMP DEFAULT
CURRENT_TIMESTAMP,
KEY idx_created_at (`created_at`)
)ENGINE=InnoDB TTL='created_at@259200';この文を使用して、テーブルに TTL プロパティがあるかどうかをクエリできます。
パラメーターの説明
TTL によって期限切れになったデータのパージを制御するために、次のグローバルパラメーターが利用可能です:
PolarDB コンソールで次のグローバルパラメーターを変更して、期限切れデータのクリーンアップを制御できます。
パラメーター名 | 説明 |
loose_innodb_enable_ttl_purge | TTL で期限切れになったデータのクリーンアップを有効にするかどうかを指定します。 有効な値:
説明 コンソールに移動して、TTL で期限切れになったデータのクリーンアップ機能を有効にする必要があります。 |
loose_innodb_ttl_min_interval | データの有効期限を設定するときに許可される最小時間。デフォルト値は 100 です。デフォルト単位は秒です。 |
loose_innodb_ttl_purge_thread | TTL で期限切れになったデータをクリーンアップするためのスレッド数。このパラメーターを変更した後、変更を有効にするには、 |
loose_innodb_ttl_cluster_index_purge_batch_size | 指定された TTL 列にインデックスがない場合、プライマリキーが TTL で期限切れになったデータについてスキャンされます。プライマリキーから一度にスキャンされる行数は、デフォルトで 10,000 です。 |
loose_innodb_ttl_index_purge_batch_size | 指定された TTL 列にインデックスが付けられている場合、このインデックスは TTL で期限切れになったデータについてスキャンされます。このインデックスから一度にスキャンされる行数は、デフォルトで 500 です。 |
loose_innodb_ttl_purge_start_hour | TTL クリーンアップタスクの開始時刻。デフォルト値は 0 です。値の範囲は 0 ~ 23 です。値は |
loose_innodb_ttl_purge_end_hour | TTL クリーンアップタスクの終了時刻。デフォルト値は 0 です。値の範囲は 0 ~ 23 です。値は |
loose_innodb_ttl_finished_job_expired_days |
|
TTL を監視する
システムは定期的に TTL ランタイム情報を収集します。mysql.ttl_job_history システムテーブルで TTL クリーンアップタスクの実行ステータスを表示できます。次の表に、このテーブルのフィールドを示します。
列名 | 説明 |
job_id | TTL クリーンアップタスクの ID。通常はミリ秒単位のタイムスタンプです。 |
table_name | この TTL ジョブによって実行されたタスクに対応するテーブルの名前。 |
state | TTL タスクの実行ステータス。pending、executing、completed など。 |
start_time | タスクの開始時刻。 |
finished_time | タスクの完了時刻。 |
expire_time | この TTL タスクによってクリーンアップされたデータの有効期限。 |
scan_cost | このバッチのスキャンに消費された時間。 |
purge_cost | このバッチのクリーンアップに消費された時間。 |
purge_rows | この TTL タスクによってクリーンアップされたデータ行の数。 |