Правила 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 не применяются из-за недостаточного числа рабочих потоков во фоновом пуле. Например, при интенсивной вставке данных весь фоновый пул может быть занят обычными слияниями. Однако размер фонового пула можно увеличить.
Проверить текущий размер фонового пула можно с помощью этого запроса:
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%'