Plausible Analytics 自托管 ClickHouse 集群部署问题解析

在自托管 Plausible Analytics 时，用户尝试配置 ClickHouse 数据库使用 ReplicatedMergeTree 引擎并添加 ON CLUSTER 语句时遇到了迁移执行失败的问题。本文将深入分析这一技术挑战的根源，并提供可行的解决方案。

问题背景

Plausible Analytics 默认使用 ClickHouse 作为其事件数据存储引擎。在单机部署场景下，MergeTree 引擎足以满足需求。但当用户需要构建高可用集群时，就需要使用 ReplicatedMergeTree 引擎并配置集群参数。

用户尝试通过配置 ecto_ch 的 default_table_options 来全局设置集群参数：

config :ecto_ch,
  default_table_engine: "ReplicatedMergeTree",
  default_table_options: [{:cluster, "default"}]

问题原因分析

迁移失败的根本原因在于 Plausible 的数据库迁移脚本采用了两种不同的实现方式：

1. Ecto 迁移：使用 Elixir 的 Ecto 框架编写，部分表定义直接使用字符串形式的 SQL 片段
2. 原生 SQL 迁移：直接使用 ClickHouse 的 SQL 模板文件

当用户设置 default_table_options 时，Ecto 尝试将这些选项与迁移中的字符串定义合并，导致了类型不匹配的错误。此外，原生 SQL 迁移完全不使用 Ecto 配置，因此全局设置对这些迁移无效。

解决方案

方案一：手动初始化数据库结构

1. 根据项目中的 structure.sql 文件手动创建所有表结构
2. 在创建语句中添加集群参数和复制配置
3. 完成初始化后启动 Plausible 并运行自动化迁移

方案二：使用 DDL 代理中间件

有开发者实现了一个 HTTP 代理解决方案，能够在运行时动态修改 DDL 语句：

1. 代理拦截所有发送到 ClickHouse 的 CREATE TABLE 语句
2. 自动添加集群配置和复制参数
3. 将修改后的语句转发到 ClickHouse 服务器

这种方法无需修改 Plausible 源代码，通过中间层透明地解决了迁移问题。

架构建议

对于生产环境的高可用部署，建议采用以下架构：

1. 使用 3 节点 ClickHouse 集群确保数据冗余
2. 为 ZooKeeper 配置奇数个节点管理复制状态
3. 在应用层配置读写分离，将分析查询分散到不同副本
4. 定期监控复制延迟和集群健康状态

总结

Plausible Analytics 的自托管集群部署确实存在一些技术挑战，主要源于迁移脚本的实现方式。通过手动初始化或使用中间件代理，用户可以成功构建高可用的 ClickHouse 集群环境。未来版本的 Plausible 可能会提供更完善的集群支持，但目前这些解决方案已经能够满足生产环境的需求。