Что такое репликация в ClickHouse
Что проверяют
Работали ли вы с кластером, а не с одиночным сервером. ClickHouse устроен иначе, чем классические СУБД, и по ответу сразу видно, читал ли человек документацию или переносит опыт PostgreSQL.
Как отвечать
Репликация в ClickHouse настраивается на уровне таблицы: её обеспечивают движки семейства ReplicatedMergeTree, в параметрах указывается путь в координаторе и имя реплики, обычно через макросы с номером шарда и реплики. Таблицы других движков не реплицируются вовсе.
Координацию ведёт ZooKeeper или ClickHouse Keeper, совместимый по протоколу и поставляемый вместе с сервером. Координатор хранит метаданные и журнал операций; сами данные через него не идут, реплики скачивают куски данных друг у друга.
Реплики равноправны, писать можно в любую. По умолчанию репликация асинхронная: вставка подтверждается той репликой, которая её приняла, остальные догоняют. Нужна гарантия нескольких копий на момент ответа, включают кворум вставки. Повторная вставка того же блока отбрасывается по контрольной сумме, поэтому повтор после сетевой ошибки безопасен и не даёт дублей.
Отдельно держите в голове разницу: таблица Distributed это про шардирование, то есть разные данные на разных узлах, а Replicated про копии одних и тех же данных. В боевом кластере обычно оба механизма сразу.
Где спотыкаются
Называют репликацию ClickHouse синхронной и говорят, что вставку подтверждают все реплики. По умолчанию хватает одной, ожидание кворума включается явно и стоит задержки на вставке.
Путают шардирование с репликацией и ждут отказоустойчивости от Distributed. При потере узла без реплик исчезает его часть данных, а запросы начинают отдавать неполный результат.
Недооценивают координатор. Он держит очередь репликации и мутаций, поток мелких частых вставок нагружает его быстрее, чем сами узлы, а зависшая очередь означает разъехавшиеся данные между репликами при формально живом кластере.