Журнал репликации и восстановление

Репликация в ClickHouse асинхронна и координируется через Keeper. Когда реплика получает вставку или выполняет merge, она записывает задачу в журнал репликации в Keeper. Все остальные реплики читают этот журнал и выполняют те же операции локально. Keeper гарантирует, что все реплики видят записи в одинаковом порядке.

Типы записей в очереди репликации

Журнал репликации содержит 7 типов записей. Каждый тип соответствует определённой операции над данными или схемой.

Мониторинг

Для мониторинга состояния репликации используются системные таблицы system.replication_queue и system.replicas.

-- Очередь репликации: незавершённые задачи
SELECT
    database,
    table,
    type,
    create_time,
    required_quorum,
    source_replica,
    num_tries,
    last_exception
FROM system.replication_queue
WHERE last_exception != ''
ORDER BY create_time DESC
LIMIT 20;

-- Состояние реплик: is_readonly, отставание по количеству частей
SELECT
    database,
    table,
    is_leader,
    is_readonly,
    is_session_expired,
    queue_size,
    inserts_in_queue,
    merges_in_queue,
    log_max_index,
    log_pointer,
    last_queue_update_exception
FROM system.replicas
WHERE is_readonly = 1 OR queue_size > 100
ORDER BY queue_size DESC;

Поле log_max_index - log_pointer показывает отставание реплики в записях журнала. Поле queue_size — количество задач в очереди. При is_readonly = 1 реплика не принимает записи.

Процедуры восстановления

SYSTEM SYNC REPLICA

Ждёт, пока реплика выполнит все задачи из очереди репликации. Блокирующая операция.

-- Дождаться синхронизации реплики (блокирует до завершения)
SYSTEM SYNC REPLICA db.events_local;

-- Облегчённый вариант: синхронизация только inserts (без merges)
SYSTEM SYNC REPLICA db.events_local LIGHTWEIGHT;

SYSTEM RESTORE REPLICA

Переводит сломанную реплику в режим восстановления. Сбрасывает метаданные Keeper для этой реплики и заново скачивает все части от других реплик.

-- Восстановить реплику: сброс метаданных + повторное скачивание всех частей
SYSTEM RESTORE REPLICA db.events_local;

Применяется когда реплика в состоянии broken: несогласованные данные, повреждённые части, ошибки при мутациях. После выполнения реплика переходит в состояние Recovering и начинает скачивать части от других реплик.

SYSTEM DROP REPLICA

-- ОСТОРОЖНО: удаляет реплику из Keeper навсегда
-- Выполнять только когда узел физически недоступен и не вернётся
SYSTEM DROP REPLICA 'clickhouse-02' FROM TABLE db.events_local;

Ключевые выводы

1. Журнал репликации содержит 7 типов записей: GET_PART, MERGE_PARTS, MUTATE_PART, ATTACH_PART, DROP_RANGE, REPLACE_RANGE, ALTER_METADATA.
2. GET_PART — самый частый тип: возникает при любом отставании реплики, включая нормальный запуск после перезагрузки.
3. system.replication_queue показывает незавершённые задачи с ошибками; system.replicas — общее состояние всех реплик.
4. SYSTEM SYNC REPLICA LIGHTWEIGHT — лёгкий вариант синхронизации, только для вставок. Полный SYSTEM SYNC REPLICA ждёт завершения всех задач включая merges.
5. SYSTEM RESTORE REPLICA сбрасывает метаданные реплики и запускает повторную синхронизацию — основной инструмент восстановления.
6. SYSTEM DROP REPLICA необратима — удаляет реплику из Keeper. Использовать только при физическом уничтожении узла.