如何解决Ignite JDBC执行INSERT...SELECT时的“Already in Cache”错误？

问题描述 #

通过JDBC（端口10800）连接云端Ignite集群，向包含THE_KEY（主键）、MY_OTHER_ID、SOME_DATA三列的MY_TABLE表插入数据：

• 直接插入THE_KEY重复的记录时，会正常返回重复插入错误，符合预期。
• 当表为空时执行以下语句：

INSERT INTO MY_TABLE (THE_KEY, MY_OTHER_ID, SOME_DATA)
SELECT ?, ?, ?
WHERE NOT EXISTS (SELECT 1 from MY_TABLE WHERE MY_OTHER_ID = ?)

会触发错误：

OperationError: 50000: Failed to INSERT some keys because they are already in cache [keys=[123]]

额外情况：虽然报错，但数据已成功插入；该问题仅在连接云端Ignite时出现，本地单节点Ignite无此问题。

• 分布式集群的执行原子性窗口问题
  本地单节点Ignite中，INSERT...SELECT WHERE NOT EXISTS的子查询与插入操作是原子执行的，不存在节点间同步延迟。但云端多节点集群下，Ignite会将SQL查询拆解到对应数据分区的节点执行：子查询先确认表为空，随后发起插入请求，但在分布式环境下，插入操作的全局同步存在短暂窗口，节点内部的重复键检测逻辑可能在全局数据同步完成前，误判主键已存在，从而抛出错误，但实际上插入操作已经成功完成。

• 云端Ignite的配置/版本差异

  • 缓存事务模式差异：本地可能使用ATOMIC缓存模式（轻量级、无事务），而云端配置为TRANSACTIONAL模式。分布式事务的锁机制在处理INSERT...NOT EXISTS这类跨节点语句时，可能因为锁的范围或同步时机问题，触发误判。
  • 版本BUG：本地使用的Ignite版本不存在该分布式场景下的逻辑缺陷，而云端部署的版本存在INSERT...NOT EXISTS在空表场景下的重复键检测BUG，导致错误报告与实际插入结果不一致。
  • 缓存写入策略：云端若开启了write-behind（异步写入）模式，插入操作的确认信号与实际数据写入存在延迟，可能导致重复检测逻辑误触发错误。

• JDBC驱动的重试机制干扰
  云端网络环境可能存在短暂的抖动或延迟，JDBC驱动自动触发了请求重试：第一次请求已成功插入数据，重试请求因主键重复触发错误，最终用户看到的是重试后的错误信息，但实际数据已由第一次请求写入。

内容的提问来源于stack exchange，提问作者Darius X.