2026-06-29 ~ 2026-07-05
本周无公告
讨论主要围绕是否将 Kafka 默认重置策略从 'latest' 改为 'by_duration'（如 PT5S），以防止分区扩展时的静默数据丢失。参与者权衡了更改默认值对现有工具的影响与数据安全性，并提出了在 4.x 或 5.0 版本实施变更的不同方案。
@Jun Rao: 反对更改默认值，认为大多数用户不扩展分区，更改默认值会带来意外的行为变更，建议保留现状并通过文档说明解决方案。
@黃竣陽: 支持更改默认值，认为文档无法解决静默数据丢失问题，倾向于在 4.4 版本直接修改默认值（方案 B）以尽快修复正确性问题。
@Chia-Ping Tsai: 支持更改默认值以提供开箱即用的安全方案，倾向于遵循弃用周期在 5.0 版本落地变更（方案 A），并建议调整控制台消费者工具的行为。
目前讨论尚未达成最终共识，Jun Rao 对更改默认值的必要性仍持保留意见，社区需进一步权衡用户影响与数据安全性。
讨论围绕 KIP-1347 展开，该提案提议在存储格式化时覆盖 Voter 集合以恢复无法形成 Quorum 的 KRaft 集群。重点讨论了在多数 Controller 丢失场景下的元数据风险，以及是否应支持从持有最长日志的 Broker 进行恢复。
@Abhijeet Kumar: 承认丢失多数 Controller 会导致元数据丢失（如 ISR 过时），但认为覆盖 Voter 集合仍是运维人员恢复集群操作的必要路径。
@Anton Agestam: 指出 KIP-1347 似乎不支持从持有最长日志副本的 Broker 恢复，而 Aiven 的内部工具支持此功能以降低 Leader Epoch 下降的风险。
@Paolo Patierno: 发起该 KIP 讨论，旨在解决 KRaft 控制器灾难恢复中无法形成 Quorum 的问题。
讨论揭示了 KIP 当前方案可能不支持从 Broker 节点恢复最长日志的局限性，后续需进一步明确 KIP 的适用范围及是否借鉴 Aiven 的开源工具经验来完善恢复机制。
KIP-1265 的代码变更已成功合并，作者通知社区对进行中的工作进行 rebase。Chia-Ping Tsai 对实现和插件设计给予好评并提出审查意见，Ashwin 随后创建了新的 PR 和 JIRA 以修复相关问题。
@Ashwin: 宣布 KIP-1265 变更已合并，并针对审查反馈创建了新的修复 PR (#22772) 和 JIRA (KAFKA-20779)。
@Chia-Ping Tsai: 赞赏代码实现和插件设计，并在原 PR 中留下了具体的审查意见。
主要代码已合并，后续工作集中在处理审查反馈的修复上，等待社区对新 PR 的反馈。
讨论围绕 KIP-1320 展开，提议弃用公共 Utils 类并引入内部替代，以解决 KIP-1265 无法提供编译期警告和明确移除时间表的问题。Eric Chang 进一步建议将该 KIP 重塑为一项通用政策，针对公共包中的内部类制定不同的弃用与移除策略，并提供了 PoC 代码演示具体实施方案。
@Chia-Ping Tsai: 询问在已有 KIP-1265 的情况下，为何仍需实施 KIP-1320。
@Eric Chang: 指出 KIP-1265 仅通过注解标记，缺乏编译器警告和截止时间，KIP-1320 旨在通过 @Deprecated 提供明确信号和移除政策。
@Eric Chang: 提出应根据外部使用情况分类处理（如移至内部包、原地弃用或仅政策覆盖），并提供了 PoC 示例。
Eric 正在征求关于将 KIP 重构为“政策导向”方案的意见，若可行将完善提案细节。
讨论主要围绕 KIP-1279（集群镜像）的提案审查展开，Mickael Maison 针对元数据调度、主题删除处理、权限控制及配置镜像等细节提出了多项改进建议。Federico Valeri 对所有反馈进行了详细解答，澄清了设计逻辑并接受了大部分修改，已更新 KIP 文档。
@Mickael Maison: 指出元数据刷新职责描述不清，询问如何识别源端已删除主题，并建议 DeleteClusterMirror RPC 应使用 Delete 权限而非 Alter。
@Federico Valeri: 确认元数据逻辑已调整，源端删除的主题在目标端将标记为 FAILED 状态以便识别，同意修正权限操作类型。
@Federico Valeri: 说明配额配置默认不镜像（遵循 MM2 逻辑），事务隔离级别目前硬编码但可在后续 KIP 中支持配置。
大部分审查意见已达成共识并更新至 KIP 文档，部分非关键功能（如事务隔离级别配置）推迟至后续 KIP 处理。
讨论主要围绕 KIP-1315 的版本规划与 API 返回类型定义展开。作者 Nilesh 根据反馈明确了变更将在 Kafka 4.x 引入并在 5.0 版本移除旧功能，同时补充了 Java 返回类型以完善 OpenAPI 规范。目前提案已解决主要疑虑，准备进入投票阶段。
@Mickael Maison: 指出移除操作仅在主版本进行，建议明确 N+1 为 Kafka 5.0，并要求在 KIP 中描述 Java 返回类型以确定 OpenAPI 规范。
@nileshkumar3: 更新 KIP 将版本具体化（4.x 引入，5.0 移除），并定义了 GET /connectors 和 GET /connectors-details 的具体返回类型。
@nileshkumar3: 说明新类型的线路格式与现有格式字节级一致（未请求字段省略而非置空），确保了兼容性。
作者已根据反馈完成 KIP 更新，若无重大异议，计划于下周发起投票。
本讨论主要针对 KIP-1363 提案，旨在为 kafka-metadata-shell 工具引入 --checkpoint 选项以替代现有的 --snapshot 选项。发起人 onebywang 已发布相关 KIP、JIRA 和 PR，目前正征求社区反馈。
@onebywang: 建议新增 --checkpoint 作为读取元数据检查点文件的首选选项。
@onebywang: 保留 --snapshot 和 -s 作为已弃用别名，以确保向后兼容性。
目前处于征集反馈阶段，尚无明确结论。
讨论围绕 KIP-1295（为全局存储/KTable 增加 DLQ 支持）展开，作者 Arpit Goyal 针对 Lucas Brutschy 的审阅意见进行了详细回复。主要探讨了全局线程避免使用 EOS 逻辑、使用非事务性生产者以及异常处理机制等具体实现细节。
@Arpit Goyal: 建议全局线程不采用 EOS 特定逻辑，而是使用专用的非事务性生产者以避免架构变更和 ID 冲突。
@Arpit Goyal: 计划在 StateConsumer 中增加异常检查调用，确保异步 DLQ 发送失败能被及时发现而非被静默吞掉。
@Arpit Goyal: 将在 KIP 中明确记录配置项行为变更的兼容性影响，并更新相关文档。
作者计划根据讨论结果更新 KIP 文档（包括兼容性说明和 Javadoc），并等待审阅者确认是否达成一致。
讨论主要围绕 KIP-1352 中是否支持“FOLLOWING”范围（前瞻）以及 RangeAggregator 的接口设计展开。Hannes 提议将前瞻功能设为可选方法以保持与 Flink 的一致性并减少用户困惑，同时探讨了通过调整迭代器接口来解耦聚合器与范围。目前作者正在征求社区对设计方案的建议。
@Hannes Buseyne: 建议将“after”查找功能从构造函数移至可选的 `.withLookAhead()` 构建器，以在支持乱序事件检测的同时避免用户混淆。
@Hannes Buseyne: 为解决命名冲突并解耦，希望 RangeAggregator 能访问包含元数据的 `Iterable
提出了将前瞻功能改为可选配置的初步方案，等待进一步反馈以决定是否保留该功能或调整接口设计。
该邮件主要是一封关于 Kafka 4.0 分支更新的自动通知，显示开发者 Viktor 推送了版本升级至 4.0.2 的代码变更。具体操作包括合并 '4.0.2-rc1' 标签以及更新相关配置文件中的版本号。另外，用户 Mike Marzo 在回复中请求退订邮件列表。
@Viktor: 推送代码将版本升级至 4.0.2，并合并了 '4.0.2-rc1' 标签到 4.0 分支。
@Mike Marzo: 发送退订请求。
Kafka 4.0 分支已完成版本号更新和 RC1 合并，涉及 gradle.properties 等多个文件的修改。
本周新建 48 个 Issue
本周 JIRA 主要集中在 Kafka Streams 和事务状态存储的稳定性与测试覆盖率扩展，修复了 RocksDB 在 EOS 模式下的重启失败及查询异常等问题。其次，涉及大量消费者组与客户端的改进，包括静态成员 ID 校验、AsyncKafkaConsumer 性能优化及 DLQ 功能完善。此外，还修复了 Jackson-databind 相关的安全漏洞（CVE）以及部分连接认证与 KRaft 迁移问题。