Flink1.13.2 HA模式下TaskManager从1扩容到2仅单个TM分配slot问题咨询

常规HA模式下新注册TM无slot分配问题排查 #

• 首先核对作业并行度与单TM slot容量的匹配关系：如果作业总并行度刚好等于单TaskManager的taskmanager.numberOfTaskSlots配置值，Flink ResourceManager默认会优先将所有任务调度到现有已使用的TM上，不会主动分散到新注册的空闲TM，只要并行度需求被完全满足，多余TM就会保持空闲状态。可通过命令flink list -r查看运行作业的实际并行度，和单TM的slot配置做核对。
• 调整slot分配策略：1.13版本默认slot分配策略不会强制均匀分布，你可以将配置项cluster.evenly-spread-out-slots设置为true，开启后ResourceManager会主动将slot分配请求均匀分散到所有已注册的TM上，即可实现扩容后TM的资源利用。
• 排查HA元数据残留问题：如果上述配置都正常，大概率是ZooKeeper中存储的ResourceManager slot元数据存在残留，导致新TM的slot未被识别。可以停掉集群后，清理ZK中/flink/{你的集群ID}/resourcemanager路径下的残留数据，再重启集群即可恢复。

Reactive模式下已知问题处理 #

• 新增TM触发作业全量重启是Flink 1.13版本Reactive模式的原生设计限制，该版本的Reactive模式属于早期试用版本，扩缩容时会触发全作业拓扑重部署，该逻辑在Flink 1.15及以上版本已经优化为增量扩缩容，不会触发全作业重启。
• 日志中的Name collision: Group already contains a Metric with the name报错是1.13版本Reactive模式的已知Bug，原因是作业重启时旧的指标实例未被及时销毁，新实例注册时出现重名冲突。临时解决方案可以配置metrics.jmx.exclude-regex: .*临时关闭冲突指标上报，也可以升级到Flink 1.13.6及以上的维护版本，该Bug已经在后续小版本中被修复。
• checkpointing、uptime、downtime等指标未正常更新是上述指标注册冲突导致的衍生问题，修复指标冲突后即可恢复正常采集。

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