调整snuba-commit-log主题分区数从1到2后出现KeyError:1的问题求助

我之前在处理Sentry 22.x版本的Snuba服务时碰到过完全一样的问题，这个错误的根源是订阅调度器的内部状态没有和新的Kafka分区数同步。

问题原因分析 #

当你把snuba-commit-log主题的分区从1增加到2后，Snuba的subscriptions_scheduler_executor进程在启动时是基于旧的分区数（1）初始化的调度器实例集合。当Kafka的消息从新的分区（分区ID=1）过来时，调度器找不到对应分区的实例，就会抛出KeyError: 1。

在Sentry 22.6.0这个版本，Snuba的订阅调度组件还不支持动态感知Kafka主题的分区变化，必须通过重启服务+清理状态的方式让它重新识别新的分区配置。

具体解决步骤 #

1. 停止所有订阅调度器进程
   首先找到并停止所有运行subscriptions_scheduler_executor命令的Snuba进程：

   # 示例：用ps查找进程并kill
   ps aux | grep subscriptions_scheduler_executor
   kill <进程ID>
   

2. 清理Snuba的状态存储
   Snuba的订阅调度状态存在Redis里，需要清理相关的键值来重置状态：

   # 进入Redis客户端
   redis-cli
   # 删除订阅相关的状态键（前缀通常是snuba-subscriptions-*）
   DEL snuba-subscriptions-scheduler:*
   

   如果你不确定具体的键名，可以用KEYS snuba-subscriptions-*来查看所有相关键，再批量删除。

3. 重新启动订阅调度器进程
   按照你的部署方式重新启动subscriptions_scheduler_executor服务，比如用docker-compose或者systemd：

   # 示例docker-compose方式
   docker-compose restart snuba-subscriptions-scheduler
   

   启动后，调度器会重新读取snuba-commit-log主题的分区数，自动创建对应数量的调度实例。

4. 验证修复效果
   观察Snuba的日志，确认不再出现KeyError:1，同时检查订阅任务（比如告警订阅、查询订阅）是否正常执行，之前的超时问题是否得到缓解。

额外注意事项 #

• 如果你是通过集群部署Snuba，要确保所有节点的调度器进程都完成重启和状态清理，避免出现状态不一致的情况。
• 增加分区后，还要检查Snuba消费者组的配置，确保新的分区能被消费者均匀分配，这样才能真正解决之前的超时问题。

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