Apache Ignite 2.15.0节点扩容时数据重平衡异常致节点崩溃咨询

问题1："Will not own partition (there are owners to rebalance from)" 是否与第二个节点崩溃有关？ #

这条DEBUG级日志不是直接导致节点崩溃的原因，它是Ignite重平衡过程中的正常流程日志。节点崩溃的直接触发点是后续出现的Blocked system-critical thread has been detected错误——该错误表明系统核心线程被长时间阻塞，最终导致节点被强制关闭。

问题2：该DEBUG信息的含义及处理方式 #

含义 #

这条日志表示：在新节点加入后的分区拓扑调整阶段，对于CustomCacheItem缓存的第3个分区，集群中已经存在可用的分区所有者（即第一个节点）。新节点不需要立刻成为该分区的所有者，而是会从已有的所有者节点拉取数据完成重平衡，待重平衡完成后才会成为该分区的合法所有者之一。这是Ignite分布式缓存分区管理的正常逻辑，用于保证数据一致性和重平衡的有序性。

处理方式 #

针对这条日志本身不需要做任何处理，它不是异常信息。需要聚焦解决后续的系统核心线程阻塞问题。

问题3：定位"Blocked system-critical thread has been detected"的触发原因 #

可以通过以下步骤逐步排查：

• 抓取线程快照：当错误出现时，立即执行jstack <第二个节点的PID>命令生成线程dump，找到名为exchange-worker-#50的线程，查看其调用栈，确定它卡在哪个方法、哪个资源上（比如网络IO、磁盘IO、锁竞争、第三方调用等）。
• 检查网络与磁盘状态：
  • 验证两个节点之间的网络连通性，检查带宽、延迟、是否存在丢包或防火墙限制，重平衡依赖节点间的高效数据传输，网络瓶颈会导致线程阻塞。
  • 检查节点的磁盘IO使用率，如果磁盘读写负载过高，会导致重平衡过程中数据读写缓慢，阻塞核心线程。
• 检查缓存配置：
  • 查看CustomCacheItem缓存的重平衡策略（如是否设置为SYNC同步重平衡），同步重平衡会等待数据完全复制完成才会结束，容易导致线程长时间阻塞；可尝试临时改为ASYNC异步重平衡验证。
  • 检查缓存的分区数、备份数是否合理，过大的分区数或备份数会加重重平衡负载。
  • 验证缓存数据的序列化/反序列化逻辑，若序列化效率低下，会拖慢数据传输速度。
• 分析详细日志：将Ignite的日志级别调整为TRACE，观察exchange-worker线程在阻塞前的所有操作日志，排查是否存在慢查询、锁等待、资源获取超时等情况。
• 监控JVM状态：使用jstat、jconsole或jvisualvm监控节点的GC情况，若存在频繁Full GC或内存不足，会导致核心线程被长时间暂停，触发该错误；同时检查JVM的堆内存、栈内存配置是否合理。

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