Kafka 4.4.0 回退到 4.3：能起来，能力掉回 4.3-IV0

预发或生产里，数据目录已经用 Kafka 4.4.0 的 kafka-storage 格式化过，现在又想把 broker 回退到 4.3.1：进程能起来，但 FeaturesPublisher 会落到 4.3-IV0，share 等能力 silently 缩水。官方把这件事标成 Notable changes：格式化目录不再向前兼容，broker 版本必须大于等于执行 format 的工具版本。回退前先确认目录是不是 4.4 工具写过的盘，再用 FeaturesPublisher 核对会丢什么，不要只看「能不能 start」。

许可证 Apache-2.0。仓库 apache/kafka。主源见 4.4.0 官博公告、Supported 下载页、RELEASE_NOTES 与 KIP-1170。

回退前先看目录

4.4.0（KIP-1170）把原先写在 bootstrap.checkpoint 里的启动元数据并进 zero checkpoint。combined 节点（process.roles=broker,controller）上，两边 format 命令相同：

bin/kafka-storage.sh format -t "$CLUSTER_ID" -c server.properties --standalone

4.3.1 工具格式化后，目录里通常有（摘录）：

meta.properties
bootstrap.checkpoint
__cluster_metadata-0/00000000000000000000-0000000000.checkpoint

4.4.0 工具格式化后（摘录）：

meta.properties
__cluster_metadata-0/00000000000000000000-0000000000.checkpoint

没有 bootstrap.checkpoint，基本可以判断这是 4.4 这一套盘。再用 kafka-dump-log.sh --cluster-metadata-decoder 看 zero checkpoint，FEATURE_LEVEL_RECORD 已经在里面，例如（摘录）：

| offset: 3 ... FEATURE_LEVEL_RECORD ... "name":"metadata.version","featureLevel":33
| offset: 6 ... FEATURE_LEVEL_RECORD ... "name":"share.version","featureLevel":2

4.3.1 格式化时，同类记录写在 bootstrap.checkpoint 里；当时的 zero checkpoint 只有 SnapshotHeader / KRaftVersion / KRaftVoters / SnapshotFooter 一类控制记录。

4.4.0 的 kafka-storage format --help 在 --release-version 说明里写明（摘录）：

Note: formatted directories are not forward-compatible — the broker version
must be greater than or equal to the kafka-storage tool that formatted the
directory, regardless of this setting.

默认初始 feature 是 4.4-IV2。即使显式传 --release-version 4.3，目录布局仍是 4.4 这一套（没有 bootstrap.checkpoint），帮助文本也强调「跟这个参数无关」。format 工具版本本身就锁住了可回退范围。

怎么验：两个独立进程

要核对「回退会不会 silently 缩水」，准备两份互不影响的数据目录，都用 4.4.0 的 kafka-storage 格式化（默认 release-version，写出 metadata.version 为 4.4-IV2 / featureLevel=33）。然后分别启动两个独立进程：

# 进程 A：4.4.0 二进制
kafka_2.13-4.4.0/bin/kafka-server-start.sh server-44.properties

# 进程 B：4.3.1 二进制（另一份 log.dirs）
kafka_2.13-4.3.1/bin/kafka-server-start.sh server-43.properties

两边都能打出 Kafka Server started。差别在 FeaturesPublisher（摘录）：

# 4.4.0
Loaded new metadata FinalizedFeatures(metadataVersion=Optional[4.4-IV2], finalizedFeatures={group.version=1, streams.version=1, transaction.version=2, eligible.leader.replicas.version=1, share.version=2, metadata.version=33}, finalizedFeaturesEpoch=11).

# 4.3.1
Loaded new metadata FinalizedFeatures[metadataVersion=4.3-IV0, finalizedFeatures={metadata.version=30}, finalizedFeaturesEpoch=5].

4.4.0 加载了 format 写进去的整组 feature，包含 share.version=2。4.3.1 同样「起来了」，但 finalized 里只剩 metadata.version=30，等价于自己这一代的默认档，并没有把 zero checkpoint 里那批 bootstrap 记录当成启动元数据用上。

能不能回、回了丢什么

决策可以压成三句：

• 能不能回：旧二进制往往还能把进程拉起来，不能把「started」当成兼容通过。
• 回了丢什么：finalized feature 会掉到 4.3-IV0；像 share.version=2 这类只在 4.4 盘里写进去的能力，回退后不再按 4.4 档位生效。
• 实务边界：哪个版本的 kafka-storage 写过盘，后面就用同版本或更新的 broker 去起。旧盘（仍带 bootstrap.checkpoint）按 KIP-1170 的兼容路径，新版本 controller 仍能处理；反过来不成立。

官博和升级说明把这件事标成 Notable changes，不是运行时可选开关。回退或跨版本共用目录前，先看有没有 bootstrap.checkpoint、dump FEATURE_LEVEL，再对照 FeaturesPublisher；需要保留 4.4 档位能力时，就不要拿 4.3 二进制去接这套盘。