ClickHouse 副本同步机制与 MySQL/PostgreSQL 主备同步的比较分析

最新推荐文章于 2025-09-14 11:41:38 发布

原创最新推荐文章于 2025-09-14 11:41:38 发布 · 718 阅读

CC 4.0 BY-SA版权

文章标签：

924 篇文章

订阅专栏

ClickHouse（CK）的副本同步机制与 MySQL、PostgreSQL（pg）的主备同步，本质逻辑一致：
都基于“日志驱动的异步复制”。

日志作为复制载体
- MySQL 使用 binlog 记录写入操作；
- PostgreSQL 使用 WAL（预写日志）；
- ClickHouse 使用 WAL 或 分区数据块日志（Part Log） 记录 MergeTree 引擎的写入单元。
异步复制为默认策略
- 主/源节点写入本地日志并持久化后，立即返回成功；
- 从/目标副本异步拉取日志并应用，实现最终一致性。
副本用途重合
- 高可用：主库/源副本故障时，从库/副本可接管；
- 读负载分担：副本可承接查询，缓解单点压力。

作为 OLAP 数据库，ClickHouse 的首要目标是 高吞吐写入与高并发查询。选择与 MySQL/pg 类似的主备同步机制，背后是对 性能与可用性的平衡：

复用成熟思路，降低设计复杂度
主备复制模式已在 MySQL/pg 中被广泛验证，CK 直接借鉴可避免重复造轮子。
优先保障写入性能
OLAP 常见场景是海量日志、指标快速写入。异步复制下，源副本无需等待从副本确认，写入延迟最小化，吞吐量最大化。
副本价值与 OLAP 需求契合
- OLAP 对“强一致”要求不高，更关注可用性和查询扩展；
- 因此副本主要承担 读扩展 和 灾备恢复，与 MySQL/pg 的备库定位高度一致。

流程：源副本写入日志 → 返回成功 → 日志尚未推送副本 → 源副本宕机。
风险：这部分日志可能丢失，造成“客户端认为成功，副本实际缺失”的情况。
→ 这与 MySQL/pg 的异步复制风险完全一致。

ClickHouse 提供多层防护，完全可规避：

开启 WAL，确保本地日志持久化
源副本即使宕机，也能通过 WAL 恢复数据。
启用同步复制配置
- 如 replication_alter_partitions_sync=2，源副本需等待从副本确认才返回；
- 类似 MySQL 半同步复制，彻底消除丢数窗口。
ZooKeeper 协调副本状态
避免脑裂和数据冲突，提升整体一致性保障。

机制共性：ClickHouse 与 MySQL/pg 的核心均为 日志驱动的异步复制，源于性能优先和成熟方案复用。
优势：低写入开销、支持高可用与读扩展、运维简单、可灵活选择一致性等级。
数据安全性：默认异步存在理论丢数风险，但通过 WAL 持久化 + 同步复制配置 + ZooKeeper 协调，可完全避免，与 MySQL/pg 的增强模式（半同步/同步复制）相当。