ClickHouse replication

ClickHouse replication is per-table: you use ReplicatedMergeTree instead of MergeTree, give it a ZooKeeper / ClickHouse Keeper path, and tell it which replica name this node is. Multiple servers create the same table against the same path — each knows about the others through Keeper, and they replicate inserts and merges among themselves. Unlike Postgres streaming replication, it's multi-leader: any replica accepts writes, and they converge via Keeper-coordinated log replay. What this buys you: high availability (drop a replica, queries still work), read scaling (distribute SELECTs across replicas), geographic redundancy. The gotcha: Keeper is a hard dependency — every write touches it for coordination — so Keeper latency becomes your write latency floor, and Keeper needs to be healthy or the cluster stops accepting writes. Combined with distributed tables, replication gives you sharded-and-replicated clusters where each shard is itself HA.