Keep your ClickHouse replicas in sync with practical monitoring queries. Learn to track replication lag, queue depth, and how to separate insert and query workloads across replicas.

BigData Boutique blog

Replication issues in ClickHouse are silent by nature and can accumulate unnoticed until a failover exposes stale data. The key monitoring source is the system.replicas table, which exposes per-table metrics like queue_size, inserts_in_queue, merges_in_queue, and replication_lag (computed as log_max_index - log_pointer). Alerts should fire on sustained queue growth, rising lag, active replicas dropping below total, and any replica entering readonly mode. When diagnosing lag, the recommended sequence is: check resource utilization first, then look for stuck operations in system.replication_queue, then review insert pressure. An architectural mitigation is to separate insert-facing and query-facing replicas at the load balancer or application level, reducing workload interference and giving read replicas time to catch up.

Monitoring Replication Health in ClickHouse