💬 讨论 (10)
7 条回复 · 4 位参与者
讨论围绕 KIP-1279 集群镜像功能展开，重点涉及 Unclean Leader Election 的处理算法、命令行工具优化及 API 细节完善。社区成员对授权模型、错误处理、版本兼容性及迁移路径提出了详细反馈，作者针对 Unclean Leader Election 提出的 Epoch 解决方案获得了初步认可。
@Andrew Schofield: 建议增加 --all-topics 选项以简化故障转移操作，并要求完善 RPC 授权文档、新增错误代码及明确 Admin API 的授权资源定义。
@Luke Chen: 提出通过记录 'last mirrored leader epoch' 来解决 Unclean Leader Election 导致的数据一致性问题，并已撰写相关子文档说明算法细节。
@Rajini Sivaram: 质疑当前的 ACL 授权设计，建议新增 ClusterMirror 资源类型替代 Cluster:ClusterAction，并询问了版本降级、循环镜像及 Tiered Storage 的处理逻辑。
讨论仍在进行中，尚未投票。作者需进一步回应关于 Admin API 缺失方法、MM2 迁移路径、授权模型细节及版本降级影响等问题，并整合社区反馈完善提案。
7 条回复 · 4 位参与者
讨论主要围绕 KIP-1282 展开，旨在通过引入基于时间戳的 auto.offset.reset 策略来防止分区扩容时的数据丢失。参与者深入分析了客户端与服务端时间戳的优劣，特别是针对静态成员重启的边缘情况进行了探讨，最终倾向于将方案拆分为客户端本地时间策略和服务端组时间策略。
@Chia-Ping Tsai: 指出服务端时间戳存在跨节点时钟同步难题，建议为静态成员增加显式时间戳配置，并提出了结合服务端时间戳与本地时间戳的混合方案。
@Ryan Leslie: 强调静态成员重启会导致本地时间戳重置从而引发数据丢失，认为显式配置时间戳虽有用户负担但可接受，总体支持该 KIP 方向。
@黃竣陽: 解释了时间戳方案在日志截断场景下的优势，并建议将策略分离：一种使用客户端本地启动时间，另一种依赖服务端时间戳且不可用时报错，以保证行为确定性。
初步结论是倾向于将策略分离，即保留 by_start_time（客户端时间）用于动态消费者，同时探索基于服务端时间戳的组级策略（需修改 RPC 协议），若服务端时间不可用则显式失败而非隐式回退。
5 条回复 · 1 位参与者
讨论主要围绕修正 KAFKA-20254 迁移警告的措辞展开。lucasbru 通过提交多个 PR（#825, #826, #827），修正了原文暗示修复版本已存在的误导性表述，明确指出修复将针对未来版本，并澄清该警告仅适用于将经典组迁移至新协议的场景。
@lucasbru: 原警告建议“升级到后续版本”具有误导性，因为修复版本尚未发布。
@lucasbru: 措辞应更新为“修复将针对未来版本”，避免让用户误以为当前已有修复版本。
@lucasbru: 需明确警告适用范围是“将经典组迁移到新协议”。
PR #826 和 #827 已成功合并，文档措辞已按要求修正完毕。
3 条回复 · 3 位参与者
讨论主要围绕 KIP-1242（错误路由连接的检测与处理）展开，旨在解决客户端因缓存过期连接到错误集群的问题。Andrew Schofield 根据反馈调整了错误码和配置逻辑，Luke Chen 提出的配置兼容性问题得到解决，最终方案获得通过。
@Gaurav Narula: 支持该 KIP，指出其填补了当缓存节点指向错误集群且未触发认证异常时的处理空白。
@Andrew Schofield: 将错误码改为 REBOOTSTRAP_REQUIRED 以支持集群恢复切换；建议若 recovery.strategy 设为 NONE 则禁用检查以避免升级冲突；对不支持 ApiVersions v5 的 Broker 仅做文档说明而不记录日志。
@Luke Chen: 关注配置冲突（recovery.strategy=NONE 与 cluster.check.enable=true）及旧版 Broker 兼容性问题，最终认可 Andrew 的解决方案。
针对配置兼容性和旧版 Broker 支持的讨论已达成一致，Andrew 已更新 KIP 文档，Luke 确认方案可行（LGTM）。
3 条回复 · 2 位参与者
KIP-1291 提议将 Kafka 暴露的 Linux I/O 指标从现有的 2 个扩展至 7 个，以增强 I/O 可观测性并诊断性能问题。讨论主要围绕指标类型的选择以及进程级与磁盘级指标的区分展开，最终双方达成共识。
@Manan Gupta: 质疑将单调递增的指标定义为 Gauge 而非 Counter 的合理性，并担心在多磁盘部署中，进程级指标可能被误读为磁盘级信号。
@Sahil Devgon: 解释选择 Gauge 是为了符合 Yammer Metrics 的轮询机制及与现有指标保持一致，并已更新文档明确指标反映的是聚合的 Broker 进程 I/O 而非单盘活动。
Manan Gupta 同意了 Sahil 的解释，认为提案可行；Sahil 将推进启动该 KIP 的投票流程。
2 条回复 · 2 位参与者
讨论围绕 KAFKA-20199 展开，指出 NodeToControllerChannelManagerImpl 在 controller-only 节点上使用 "BrokerId" 作为指标标签具有误导性。提议对此类节点改用 "NodeId" 标签，同时保持 broker 节点不变。鉴于涉及公共指标变更，社区建议需遵循 KIP 流程。
@nileshkumar3: 指出 controller-only 节点使用 "BrokerId" 标签存在误导，提议改用 "NodeId" 并询问是否需要 KIP。
@Chia-Ping Tsai: 提醒应查阅 KIP 页面，并指出此类公共指标变更应遵循 KIP 流程。
初步确认需要通过 KIP 流程来处理公共指标变更，下一步将由 Nilesh 起草 KIP 并发起讨论。
2 条回复 · 2 位参与者
讨论主要针对 Kafka Connect 中 `READ_WRITE_TOTAL_TIMEOUT_MS` 硬编码超时时间（30秒）在大规模任务场景下不足的问题。Henry 提议增加该值或将其可配置化，Chris Egerton 同意通过补丁增加硬编码值，但提醒需避免数值过高导致 Worker 脱离集群，且配置化需经过 KIP 流程。
@Henry Haiying Cai: 现有 30 秒超时对于 500+ 任务的环境太短，建议增加该值或使其可配置。
@Chris Egerton: 同意增加硬编码值，但配置化需 KIP；建议暂时通过调整生产者配置（如 linger.ms, batch.size）来提高吞吐量。
@Henry Haiying Cai: 询问补丁可接受的具体超时数值（60s-300s），并将尝试生产者调优。
初步同意通过补丁增加硬编码超时时间，下一步需确定具体数值，同时建议用户尝试调整生产者参数作为临时方案。
1 条回复 · 2 位参与者
讨论围绕 KIP-1249 展开，旨在改进新消费者组重平衡协议的位移重置功能。参与者提出了关于共享组支持、心跳 API 利用及 Admin Client 处理活跃组方式的问题。作者回应称当前重点在新协议，共享组支持可后续跟进，并确认了心跳 API 在新协议中的作用。
@Sushant Mahajan: 询问为何不支持共享组，并建议利用心跳 API 通知消费者暂停的分区以减少 fetch 调用。
@Sean Quah: 询问 Admin Client 在重置活跃组位移时的具体流程，例如是否需要轮询 DescribeGroup 或重试 OffsetCommits。
@Levani Kokhreidze: 回应称共享组支持可作为后续 KIP，新协议将利用心跳 API 更新分配，重点在于新协议而非即将弃用的经典组。
初步明确了该 KIP 优先支持新消费者组协议，共享组支持留待后续讨论；关于 Admin Client 处理活跃组的具体细节仍需进一步明确。
1 条回复 · 2 位参与者
讨论主要围绕 KIP-1269 中应采用 Broker 级配置还是分区级限制来控制保留批次数。PoAn Yang 认为分区级配置无法替代连接级限制且会增加复杂性，而 Andrew Schofield 建议通过客户端分区级限制来结合两者的优势。目前双方仍在探讨最佳实现方式。
@PoAn Yang: 分区级配置无法覆盖连接级背压控制的场景，且两级限制会增加复杂性。
@PoAn Yang: Broker 级配置在低延迟环境下也能显著改善因严格排序导致的延迟问题。
@Andrew Schofield: 建议让 Producer 限制分区级的请求数，以同时实现高吞吐和有序性，认为当前方案只解决了一半问题。
尚未达成明确共识，Andrew 提出了客户端侧分区级限制的替代思路，等待进一步讨论。
1 条回复 · 2 位参与者
讨论主要围绕 KIP-1191 实施层面的安全防护机制，Vaquar Khan 指出了协调器故障转移导致的数据重复、DLQ 写入受阻引发的内存压力以及缺乏熔断机制等运维风险。Andrew Schofield 回应称内存压力问题已有控制机制，并建议原子性写入和熔断机制等改进可通过后续 KIP（如 KIP-1289 或新的微型 KIP）来实现。
@vaquar khan: 指出 DLQ 写入与状态更新的非原子性会导致故障转移时产生重复数据，破坏审计追踪，建议增加去重机制。
@vaquar khan: 建议引入熔断机制，当下游服务故障导致大量消息进入 DLQ 时自动暂停组，以保护消息顺序和系统稳定性。
@Andrew Schofield: 澄清内存压力问题受限于“在途记录”数量，不会无限增长；建议熔断器等新功能通过提交新的微型 KIP 来实现。
Andrew 建议针对熔断器机制提交新的 KIP，原子性写入改进将依赖未来的 KIP-1289，当前 KIP-1191 将维持现有设计并记录局限性。