Apache Ignite 2.14(K8s)：ignite-sys-atomic-cache分区数据丢失问题求助

1. 问题产生的原因 #

• 副本配比与节点离线的冲突：3节点集群+1份备份的配置下，每个分区仅存在2个副本（主+备）。当同时重启2个节点时，若某个分区的主、备副本恰好都在这两个节点上，剩余1个节点没有该分区的任何副本。即便开启了持久化，如果节点重启前未完成数据刷盘，或者持久化存储无法正常读取，就会导致该分区的所有副本彻底丢失。
• 系统缓存的特殊性：ignite-sys-atomic-cache是Ignite存储AtomicLong/AtomicSequence等原子数据的内部缓存，它的分区配置和用户缓存组绑定（此处为default-ds-group）。常规的reset_lost_partitions命令无法直接修复系统缓存——这类缓存的重置逻辑有特殊限制，且其存储的序列状态是Ignite原子操作的依赖，丢失后直接触发操作异常。
• Kubernetes环境的不优雅关闭：Kubernetes的强制终止机制可能导致Ignite节点来不及将内存中的分区数据刷入持久化存储，或者节点重启后持久化卷挂载异常，进一步增加了副本丢失的概率。

2. 不销毁集群、不重新加载数据的修复方案 #

• 直接重置系统缓存的丢失分区
  1. 确保所有节点已启动并稳定加入集群，拓扑状态正常。
  2. 执行针对系统缓存的重置命令：

     ./control.sh --cache reset_lost_partitions ignite-sys-atomic-cache@default-ds-group
     

     若上述命令无效，可通过JMX连接任意节点，调用IgniteCacheMXBean.resetLostPartitions()方法并指定该系统缓存的全名。
  3. 重置后，AtomicSequence的ID可能出现断层，需业务侧确认是否可接受，或手动调整序列当前值至合适位置。
• 应急替换方案
  如果系统缓存重置失败，可临时将AtomicSequence替换为数据库ID生成器或本地内存序列（需评估业务对ID唯一性的要求），待集群稳定后再切换回Ignite的原子序列。

3. 预防此类问题的措施 #

• 调整副本数配置：将备份数从1调整为2，让每个分区拥有3个副本（主+2备）。这样即便2个节点同时离线，剩余节点仍能保留至少1个分区副本，避免全部丢失。
• 优化节点关闭流程：在Kubernetes的Pod配置中设置足够长的terminationGracePeriodSeconds（建议300秒），确保Ignite节点有充足时间完成数据刷盘和拓扑退出。同时在Ignite配置中启用IGNITE_WAIT_FOR_BACKUPS_ON_SHUTDOWN参数，让节点关闭前等待备份节点同步完成。
• 监控分区副本状态：通过Ignite Metrics或GridGain Portal监控所有缓存的分区副本数量，当出现副本数为0的情况时立即告警，及时介入处理。
• 升级Ignite版本：Ignite 2.14存在系统缓存分区恢复的已知bug，升级至2.15.x及以上稳定版本可修复此类问题，提升系统缓存的容错能力。
• 滚动重启节点：部署更新时采用滚动重启策略，每次仅重启1个节点，确保集群拓扑始终有足够节点维护分区副本的完整性。

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