CentOS上Kafka的版本升级如何操作 - 问答

CentOS 上 Kafka 版本升级操作指南

一升级前准备

备份关键数据与配置：包括 Zookeeper 数据目录、Kafka 日志目录（log.dirs）、以及 server.properties / zookeeper.properties 等配置文件。
检查当前版本与运行状态：在 Kafka 目录执行命令查看版本信息，例如：
find ./libs/ -name “kafka_” | head -1 | grep -o ‘kafka[^\n]*’
同时确认集群健康与复制状态。
规划升级路径：优先选择滚动升级以减小停机窗口；如跨多个大版本，先在测试环境验证兼容性与性能。
准备回退方案：保留旧版本目录与配置，确保异常时可快速回滚。

二升级路径与模式选择

使用 ZooKeeper 的传统模式（Kafka 2.x 常见）：升级时保持 inter.broker.protocol.version 与 log.message.format.version 为当前在用版本，逐台替换新版并重启；验证无误后再统一提升协议与消息格式版本，最后再滚动重启一次生效。
使用 KRaft 模式（Kafka 3.x/4.0）：不再依赖 ZooKeeper，需准备 cluster.id 并按 KRaft 要求配置 process.roles / controller.quorum.voters；首次初始化存储使用 kafka-storage.sh format；升级同样建议逐台滚动替换并验证。
版本跨度较大（如 2.x → 4.0）：务必在测试环境充分验证，关注配置项变更、参数默认值变化与客户端兼容性。

三标准操作步骤（滚动升级，适用于 ZooKeeper 模式）

在全部 Broker 上保持兼容性配置：在 server.properties 中设置
inter.broker.protocol.version=当前版本号（如：2.5、2.8 等）
log.message.format.version=当前消息格式版本（如未显式设置可先不配）
逐台升级（每次一台）：
- 停止旧 Broker：systemctl stop kafka（或按实际启停脚本）
- 解压新版本并拷贝旧配置：tar -xzf kafka_2.13-<新版本>.tgz；cp 旧版/config/server.properties 新版/config/
- 按需调整新版配置（如 listeners、log.dirs、zookeeper.connect 等）
- 启动新 Broker：systemctl start kafka
- 观察日志与监控，确认该节点已加入集群、分区 ISR 正常、无异常报错
全部节点升级完成后，统一提升协议版本：
- 将所有 Broker 的 inter.broker.protocol.version 改为新版本号
- 逐个滚动重启使其生效（此时通常已无法降级）
如曾显式设置消息格式版本，待客户端大多升级后再将 log.message.format.version 提升到新版本，并再次滚动重启。

四标准操作步骤（KRaft 模式）

准备新版本目录并拷贝旧配置：tar -xzf kafka_2.13-<新版本>.tgz；cp 旧版/config/server.properties 新版/config/
生成并格式化存储（仅需一次，按实际角色与目录执行）：
- 生成集群 ID：export KAFKA_CLUSTER_ID=“$(uuidgen)”
- 格式化：/opt/kafka/bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c /opt/kafka/config/server.properties
逐台滚动替换并启动新版本，验证节点注册、副本同步与健康状态。
如从 ZooKeeper 模式迁移至 KRaft，需按官方指引完成元数据迁移后再切换生产流量（建议在测试环境演练）。

五验证与回退

功能与连通性验证：
- 列出 Topic：bin/kafka-topics.sh --list --bootstrap-server broker:9092
- 发送/消费测试消息，确认生产与消费正常
- 检查集群与副本状态、监控延迟与错误日志
回退方案：
- 若升级异常，停止新版本，恢复旧版本目录与配置并启动；在 ZooKeeper 模式下，因已提升 inter.broker.protocol.version 通常无法降级，需谨慎操作并在测试环境充分验证。

六常见注意事项

0 赞

0 踩