JDBC Source Connector对接Spanner出现事务中止错误但数据仍可同步问题咨询

该异常是Google Cloud Spanner内置的乐观并发控制机制触发的标准错误，具体触发逻辑如下：

• Spanner默认采用乐观锁实现事务一致性，事务执行阶段不会立刻对操作的数据加锁，仅在提交阶段校验是否有其他事务修改了当前事务涉及的行范围。你遇到的AbortedDueToConcurrentModificationException，就是因为JDBC连接器执行增量查询的事务，和业务侧对order_item表的写入事务同时操作了同一主键范围的数据，Spanner判定优先级更低的查询事务需要中止。
• 你使用的timestamp+incrementing同步模式每次都会生成日志中展示的范围查询语句，当查询覆盖的行范围刚好和业务写入的行范围重叠时，就会触发冲突导致查询事务被中止。

Confluent JDBC Source Connector内置了查询失败重试机制，异常不影响最终同步的核心原因如下：

• 连接器针对可重试的数据库异常，会按照配置的retry.backoff.ms间隔自动重新执行上一次失败的查询。
• Spanner返回的AbortedException属于连接器默认识别的可重试异常类，你看到的报错仅为单次查询失败的日志，连接器后台已经自动重试成功，完成了数据采集。
• 连接器的offset提交逻辑是在数据成功写入Kafka之后才执行，重试过程不会更新offset，也不会出现数据丢失或重复的问题。

如果需要降低这类报错的出现频率，可以调整以下配置：

• 调小JDBC连接器的query.timeout.ms参数，降低单次查询的执行时长，减少事务冲突概率
• 适当调大poll.interval.ms参数，拉长查询间隔，降低查询和业务写入的冲突频率
• 为Spanner的order_item表建立updated_time + order_item_id的二级索引，加快增量查询的执行速度，缩短事务运行时间，从根源降低冲突概率

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