Cadence Workflow异常问询：UpdateShard操作影响2个分片问题

在QA环境运行Cadence Workflow时出现间歇性异常，执行工作流时偶发日志报错，错误信息为UpdateShard operation failed. Error: rowsAffected returned 2 shards instead of one，日志详情如下：

{"level":"error","ts":"2025-04-09T10:06:58.716-0300","msg":"Operation failed with internal error.","service":"cadence-history","error":"UpdateShard operation failed.  Error: rowsAffected returned 2 shards instead of one","metric-scope":2,"logging-call-at":"base.go:112"}

{"level":"error","ts":"2025-04-09T10:06:58.716-0300","msg":"renewRangeLocked failed.","service":"cadence-history","shard-id":0,"address":"myAddress:7934","store-operation":"update-shard","error":"UpdateShard operation failed.  Error: rowsAffected returned 2 shards instead of one","shard-range-id":20,"previous-shard-range-id":19,"logging-call-at":"context.go:1046"}

{"level":"error","ts":"2025-04-09T10:06:58.716-0300","msg":"Internal service error","service":"cadence-history","error":"UpdateShard operation failed.  Error: rowsAffected returned 2 shards instead of one","wf-id":"WID","wf-run-id":"","wf-domain-id":"a0460a71-e68a-4da1-a113-75767a7b6c17","logging-call-at":"handler.go:2097"}

已观察到现象：

• 间歇性错误：工作流有时运行成功，有时失败；
• 环境特异性：仅QA环境出现该问题，开发环境无异常；
• Cadence版本：1.2.15-auto-setup。

咨询问题：

1. 为何工作流会出现时成功时失败的情况？
2. QA与开发环境间的哪些状态或条件差异触发了该不一致行为？
3. 针对该问题，需排查哪些调试步骤或配置项，尤其关注两环境的差异？

1. 工作流时成功时失败的原因 #

该错误源于Cadence History服务更新分片（Shard）时，SQL操作影响了2条记录而非预期的1条，触发一致性校验失败。间歇性出现的核心原因包括：

• 分片锁并发冲突：多个History实例同时更新同一片段的range ID时，可能出现脏写或重复更新，导致数据库返回受影响行数超出预期；
• 数据库隔离级别问题：若QA环境数据库隔离级别较低（如读未提交），可能出现幻读/不可重复读，使更新操作意外匹配多条记录；
• 分片数据异常：分片表中存在重复的shard-id记录，仅在特定并发场景下触发多行匹配的更新失败。

2. QA与开发环境的差异触发点 #

仅QA环境出现问题，大概率是以下状态或配置存在差异：

• 数据库层面：
  • 事务隔离级别不一致，QA环境使用更低的隔离级别；
  • QA环境为多节点数据库集群，存在主从同步延迟或读写分离配置，开发环境为单节点；
• Cadence部署与负载：
  • QA环境History服务实例数更多、工作流并发量更大，更容易触发分片更新的竞争场景；
• 数据状态：
  • QA环境分片表存在脏数据（如重复shard-id记录），开发环境数据无异常；
  • QA环境经历过版本升级或数据迁移，遗留分片数据不一致问题；
• 配置参数：
  • 分片锁超时时间、重试次数等配置在两环境不同，QA环境重试逻辑更易触发冲突；
  • 数据库连接池配置差异，QA环境并发数据库操作更多。

3. 排查调试步骤与配置项 #

重点围绕两环境差异展开排查：

数据库层面 #

• 检查分片表数据：执行SELECT * FROM shard WHERE shard_id = 0;（对应日志中的shard-id:0），确认是否存在重复记录；
• 对比事务隔离级别：执行SHOW VARIABLES LIKE 'transaction_isolation';，确保QA环境与开发环境隔离级别一致（建议使用REPEATABLE READ）；
• 检查集群状态：若为多节点集群，确认主从同步是否正常，是否存在读写分离延迟；
• 开启慢查询日志：捕获UpdateShard对应的SQL语句，分析执行计划是否存在索引缺失或全表扫描导致的多行匹配。

Cadence配置层面 #

• 对比两环境Cadence配置文件（重点是History服务相关）：
  • 检查shard-renew-interval、shard-lock-timeout等分片锁参数；
  • 核对History服务实例数、并发处理配置；
• 分析metrics数据：重点关注cadence_history_shard_update_failed指标，关联失败时间点与负载变化；
• 开启Debug日志：将History服务日志级别调至debug，查看UpdateShard操作的SQL参数与执行上下文，确认是否存在并发更新。

数据与版本层面 #

• 检查QA环境是否经历过Cadence版本升级或数据迁移，是否存在分片数据未清理的遗留问题；
• 对比两环境分片初始化状态：确认QA环境分片是否通过标准初始化流程创建，而非手动修改数据。

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