6.1 部署与升级

6.1 部署与升级

本节摘要：本节讲 ClickHouse 的部署方式选择、配置管理、版本升级流程和回滚预案。部署选对、升级稳，运维就顺一半。

学习目标

阅读完本节，你应当能够：

1. 选择合适的部署方式（包安装/Docker/集群管理）
2. 理解关键配置项的作用
3. 执行滚动升级流程
4. 制定回滚预案

一、部署方式选择

ClickHouse 支持几种部署方式：

• 官方包安装（deb/rpm）：最常用，apt install clickhouse-server 或 yum install。适合自建机房，升级用包管理器。
• Docker：适合测试、单机试用、CI 环境。生产单机也可，但集群管理偏弱。
• 二进制：官方提供静态编译二进制，解压即用，适合无包管理器的环境。
• Kubernetes/云托管：ClickHouse Cloud 或自建 Operator，适合云原生场景。

生产集群一般用包安装或 Operator，配合配置管理工具（Ansible/Salt）批量部署。Docker 多用于测试。

二、关键配置

ClickHouse 的配置在 /etc/clickhouse-server/ 下，主配置 config.xml，用户配置 users.xml。几个关键项：

• listen_host：监听地址，生产要设成对外可达的 IP，别只 127.0.0.1。
• http_port/tcp_port：HTTP 8123、TCP 9000，按需改。
• max_connections：最大连接数，按并发规划。
• path：数据目录，指向大磁盘。
• zookeeper/keeper_cluster：协调服务地址，副本表必需。
• remote_servers：集群分片副本拓扑，Distributed 表用。

配置改动后 systemctl reload clickhouse-server 或 SYSTEM RELOAD 热加载，多数不用重启。

三、升级流程

ClickHouse 升级原则：滚动升级、副本先升一个、确认无误再升其他。典型流程：

1. 备份：升级前先备份关键数据（见 6.3）。
2. 挑一个副本：先升级一个副本，停服务、升级包、启动。
3. 验证：跑几个核心查询，确认数据正常、查询正常。
4. 滚动其余：确认无误后，逐个升级其他副本/分片，每个都验证。
5. 完成：所有节点升级完，观察一段时间。

升级期间，被升级副本下线，流量由其他副本承接。所以升级前要确认副本数足够（至少 2 副本，升一个还有一个可用）。

四、版本选择与兼容性

ClickHouse 发版很快，但版本间偶尔有不兼容变更。生产建议：

• 用 LTS（长期支持）版本，而非追最新
• 升级前看 Release Notes 的 Breaking Changes
• 跨大版本升级要测试，别直接跳

五、回滚预案

升级有风险，必须有回滚预案。回滚的难点是数据格式——新版本可能写了旧版本读不了的格式。所以：

• 升级前备份关键数据
• 回滚到旧版本前，确认新版本没写不兼容格式（或先恢复备份）
• 保留旧版本包，能快速装回

⚠️ 常见坑：有人升级后没验证就全量滚动，结果一个隐藏 bug 在所有节点爆发，想回滚发现数据格式已变。升级要"升一个、验一个、再升下一个"，别图快全量推。

💡 关键直觉：升级是高风险操作，核心是"小步快验证"——一次升一个副本，每步验证，有问题及时停。比"全量推一把梭"安全得多。

温故知新

• 部署方式：生产用包安装或 Operator，Docker 用于测试，配置在 /etc/clickhouse-server/。
• 关键配置：listen_host、端口、path、zookeeper、remote_servers，多数热加载不用重启。
• 升级流程：备份 → 升一个副本 → 验证 → 滚动其余，副本数足够才滚动。
• 版本：生产用 LTS，看 Breaking Changes，跨大版本要测。
• 回滚：升级前备份，保留旧包，回滚前确认数据格式兼容。

下一节讲监控——运维的眼睛，盯哪些指标、怎么告警。

配置热加载与健康检查

配置管理是部署的地基。ClickHouse 多数配置支持热加载，不用重启服务，但要知道改了什么、加载了什么：

-- 热加载 config.xml 等配置
SYSTEM RELOAD CONFIG;

-- 查看当前生效的配置（合并了所有配置文件）
SELECT name, value
FROM system.settings
WHERE name IN ('max_threads', 'max_memory_usage');
​

SYSTEM RELOAD CONFIG 能加载大部分配置变更，但个别配置（如监听端口、集群拓扑的某些部分）仍需要重启。生产规范是：先小范围改、验证、再推全量，和升级流程一个思路。

健康检查在运维脚本里很常用，一条 SQL 就能确认服务可用：

# 检查服务是否存活（HTTP 接口）
curl -s http://localhost:8123/ping

# 检查是否能正常执行查询
clickhouse-client --query "SELECT version(), uptime(), hostName()"
​

配合一个简单的监控脚本定期执行，就能把"服务是否可用"变成可持续观测的信号。升级流程的最后一步也是这样验证：新版本跑同样的健康检查 SQL，比对版本号和关键设置是否如预期，确认无异常再滚动下一个节点。

关于配置的版本管理，建议把 config.xml、users.xml 和集群拓扑配置纳入配置管理仓库，改配置走代码评审。生产事故里相当一部分来自"某人在某台机器上手改配置，忘了同步"——配置即代码，能省掉这类低级事故。