Кворумные записи и консистентность

По умолчанию ClickHouse использует eventual consistency: INSERT считается успешным, как только данные записаны на одну реплику, остальные реплики догоняют асинхронно через лог репликации в Keeper. Для большинства аналитических сценариев это приемлемо. Но некоторые workload-ы требуют более строгих гарантий: финансовые журналы, audit trails, критические метрики.

Кворумные настройки позволяют добавить гарантии durability и read-your-writes поверх реплицированной архитектуры ClickHouse.

Кворумный INSERT

insert_quorum требует, чтобы данные были записаны на заданное количество реплик до подтверждения клиенту:

-- Требуем подтверждения от 2 реплик из 3
INSERT INTO events_local
SETTINGS
    insert_quorum = 2,
    insert_quorum_timeout = 60000  -- 60 секунд ожидания
VALUES
    (1001, 'payment', 99.99, now());

-- insert_quorum='auto': большинство реплик (majority quorum)
-- При 3 репликах -- это 2; при 5 репликах -- это 3
INSERT INTO events_local
SETTINGS
    insert_quorum = 'auto',
    insert_quorum_timeout = 60000
VALUES
    (1002, 'refund', 49.99, now());

Если в течение insert_quorum_timeout миллисекунд кворум не достигнут (реплика недоступна или отстаёт), INSERT завершается с ошибкой. Данные при этом могут быть уже записаны на часть реплик — нужно учитывать при повторных попытках.

Sequential consistency при чтении

select_sequential_consistency=1 гарантирует, что SELECT видит только данные, записанные с кворумным подтверждением. Это реализует read-your-writes семантику:

-- Запрос видит только quorum-confirmed данные
SELECT event_id, amount, event_time
FROM events_local
WHERE event_date = today()
SETTINGS select_sequential_consistency = 1;

-- Типичный паттерн: write with quorum, read with sequential consistency
INSERT INTO events_local
SETTINGS insert_quorum = 'auto'
VALUES (1003, 'withdrawal', 200.00, now());

-- Этот SELECT гарантированно увидит строку выше
SELECT * FROM events_local
WHERE event_id = 1003
SETTINGS select_sequential_consistency = 1;

select_sequential_consistency=1 делает дополнительный запрос к Keeper перед SELECT, чтобы проверить номер последней quorum-записи. Это добавляет latency и нагрузку на Keeper.

SYSTEM SYNC REPLICA

Более лёгкая альтернатива для точечной синхронизации — дождаться, пока конкретная реплика догонит очередь репликации:

-- Полная синхронизация: ждёт пока очередь репликации опустеет
SYSTEM SYNC REPLICA db.events_local;

-- LIGHTWEIGHT: только ждёт применения последней quorum-записи
-- Не ждёт всех pending merge/mutate операций -- значительно быстрее
SYSTEM SYNC REPLICA db.events_local LIGHTWEIGHT;

-- PULL: принудительно запускает получение записей из Keeper
SYSTEM SYNC REPLICA db.events_local PULL;

SYSTEM SYNC REPLICA LIGHTWEIGHT полезен после INSERT с insert_quorum, когда нужно убедиться, что конкретная реплика видит записанные данные перед чтением с неё.

Сравнение подходов к консистентности

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

1. Eventual consistency (default) подходит для большинства аналитических workload-ов — никакой дополнительной конфигурации не требуется.
2. insert_quorum добавляет durability гарантии: данные записаны на N реплик до подтверждения клиенту. insert_quorum='auto' проще в обслуживании.
3. select_sequential_consistency=1 обеспечивает read-your-writes, но добавляет нагрузку на Keeper при каждом SELECT. Не включайте на горячих аналитических запросах.
4. SYSTEM SYNC REPLICA LIGHTWEIGHT — лёгкая альтернатива для точечной синхронизации без постоянных Keeper-запросов.
5. SharedMergeTree (Cloud) — кворумность встроена, дополнительные настройки не нужны.