Kafka 2.5.0如何降级log.message.format.version配置？

是否可以将log.message.format.version从2.5降级为2.2 #

可以降级。Kafka的log.message.format.version（简称LMFV）用于指定broker持久化消息时采用的格式版本，只要当前集群所有broker的运行版本不低于目标设置版本（本次降级目标为2.2，你的broker运行版本为2.5，完全满足要求），该操作就是合法且可执行的。

操作对生产者、消费者的影响 #

对生产者的影响 #

• 所有版本的生产者都可以正常生产消息，无可用性风险。
• 版本高于2.2的生产者发送的消息，broker会在写入磁盘前自动转换为2.2格式，会产生极少量额外CPU开销，常规吞吐量场景下几乎感知不到，仅单集群每秒写入量超过数十万级的场景需要提前做压测评估。

对消费者的影响 #

• 版本≥2.2的消费者：完全不受影响，不管是降级前已有的2.5格式存量消息，还是降级后新写入的2.2格式消息，都可以正常消费，无需任何改造，格式转换过程不会丢失任何消息数据、元数据，不影响消息语义一致性。
• 版本<2.2的消费者（包括你用到的Brooklin对应旧版本Kafka客户端）：
  1. 降级前已写入的2.5格式存量消息，broker会在返回给消费者前自动做向下格式转换，会产生少量CPU和内存开销，等存量消息按照保留策略清理完成后，这部分开销会自动消失。
  2. 降级后新写入的消息直接为2.2格式，broker不需要额外转换即可直接返回给旧客户端，消费性能优于降级前，也不会再出现版本不兼容报错。

操作注意事项 #

• 可采用滚动重启方式更新配置，不中断集群服务：先修改所有broker配置文件的log.message.format.version为2.2，逐台重启broker，每台重启完成确认集群健康后再操作下一台即可。
• 降级后如果后续计划升级Kafka集群版本，需要先将LMFV和inter.broker.protocol.version调整到对应新版本后，再升级broker运行包，避免出现兼容性问题。
• 如果业务对旧客户端兼容性要求极高，无法接受存量2.5格式消息的转换开销，可以在降级后避开业务高峰手动触发日志段合并，加速存量旧格式消息的清理。

内容的提问来源于stack exchange，提问作者Arkadiy Verman