Set up docs MCP有効期限 (TTL) ルールと制御
有効期限 (TTL) は最終的には適用されます。これはどういう意味でしょうか。MergeTree テーブル設定の merge_with_ttl_timeout は、delete 有効期限 (TTL) を伴うマージを再実行するまでの最短待機時間を秒単位で設定します。デフォルト値は 14400 秒 (4 時間) です。ただし、これはあくまで最短の待機時間であり、delete 有効期限 (TTL) のマージがトリガーされるまでには、さらに時間がかかることがあります。
次のクエリを使うと、現在の 有効期限 (TTL) 設定 (merge_with_ttl_timeout など) をすべて確認できます。
SELECT *
FROM system.merge_tree_settings
WHERE name like '%ttl%'応答は次のようになります。
┌─name───────────────────────────────────────────────────────────┬─value───┬─changed─┬─description────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬─min──┬─max──┬─readonly─┬─type───┐
│ max_replicated_merges_with_ttl_in_queue │ 1 │ 0 │ How many tasks of merging parts with TTL are allowed simultaneously in ReplicatedMergeTree queue. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │
│ max_number_of_merges_with_ttl_in_pool │ 2 │ 0 │ When there is more than specified number of merges with TTL entries in pool, do not assign new merge with TTL. This is to leave free threads for regular merges and avoid "Too many parts" │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │
│ merge_tree_clear_old_broken_detached_parts_ttl_timeout_seconds │ 2592000 │ 1 │ Remove old broken detached parts in the background if they remained intouched for a specified by this setting period of time. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │
│ merge_with_ttl_timeout │ 14400 │ 0 │ Minimal time in seconds, when merge with delete TTL can be repeated. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ Int64 │
│ merge_with_recompression_ttl_timeout │ 14400 │ 0 │ Minimal time in seconds, when merge with recompression TTL can be repeated. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ Int64 │
│ ttl_only_drop_parts │ 0 │ 0 │ Only drop altogether the expired parts and not partially prune them. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ Bool │
│ materialize_ttl_recalculate_only │ 0 │ 0 │ Only recalculate ttl info when MATERIALIZE TTL │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ Bool │
└────────────────────────────────────────────────────────────────┴─────────┴─────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴──────┴──────┴──────────┴────────┘SHOW CREATE TABLE を使うと、テーブルに有効期限 (TTL) ルールが含まれているかどうかや、テーブルの SETTINGS によって上記の設定値が変更されているかどうかを確認できます。
SHOW CREATE TABLE <TableName>有効期限 (TTL)ルールを強制的に適用する
これはあまりスマートな方法ではありませんが、MATERIALIZE TTL を明示的に実行することで、テーブルのすべての有効期限 (TTL)ルールを強制的にマテリアライズできます。
ALTER TABLE my_table
MATERIALIZE TTL有効期限 (TTL) に影響するバックグラウンドスレッド
バックグラウンドプールの稼働スレッド数が不足しているために、有効期限 (TTL) のルールが適用されていない可能性があります。たとえば、データを高頻度で insert している場合、バックグラウンドプール全体が通常のマージ処理で使われてしまうことがあります。ただし、バックグラウンドプールのサイズは増やせます。
現在のバックグラウンドプールのサイズは、次のクエリで確認できます。
SELECT *
FROM system.settings
WHERE name = 'background_pool_size';応答は次のようになります:
┌─name─────────────────┬─value─┬─changed─┬─description─────────────────────┬─min──┬─max──┬─readonly─┬─type───┬─default─┬─alias_for─┐
│ background_pool_size │ 16 │ 0 │ Obsolete setting, does nothing. │ ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ │ 0 │ UInt64 │ 16 │ │
└──────────────────────┴───────┴─────────┴─────────────────────────────────┴──────┴──────┴──────────┴────────┴─────────┴───────────┘以下のように設定されているbackground_pool_size 設定の変更方法については、ドキュメントを参照してください:
<background_pool_size>16</background_pool_size>次のクエリで、現在のバックグラウンドプールのアクティビティを確認できます。
SELECT *
FROM system.metrics
WHERE metric like 'Background%'