YugabyteDB中事务等待状态更新导致的SIGSEGV问题分析

问题背景

在YugabyteDB数据库系统中，当用户从2.18.9.0-b17版本升级到2024.2.2.2-b2版本时，系统会生成核心转储文件(core dump)。这个问题是一个回归性问题，在2024.2.2.1-b6版本中已经得到验证不会发生，但在2024.2.2.2-b2版本中仍然存在。

问题现象

系统在运行过程中出现段错误(SIGSEGV)，导致核心转储。通过分析核心转储文件，发现错误发生在TabletServiceImpl::UpdateTransactionWaitingForStatus方法中，具体是在尝试分配内存时发生的段错误。

技术分析

错误调用栈

从调用栈可以看出，错误发生在事务处理流程中，特别是与死锁检测相关的部分：

1. 系统尝试为死锁检测器(DeadlockDetector)分配内存以处理等待事务的状态更新
2. 在GetProbesToSend方法中，系统试图为本地探针处理器(LocalProbeProcessor)创建回调函数
3. 内存分配失败导致段错误

根本原因

这个问题与YugabyteDB 2024.1版本中引入的"等待队列"(wait queues)功能有关。该功能默认启用，但它是通过gflag而非autoflag实现的。由于autoflag必须是运行时标志，而enable_wait_queuesgflag不能作为运行时标志，因此在升级过程中会出现问题。

在从低于2024.1的版本升级到2024.1或更高版本时，可能会出现以下情况：

• 部分TServer节点已升级并启用了等待队列功能
• 这些节点期望所有事务都遵循等待队列行为
• 但仍有部分事务运行在未升级的TServer节点上(这些节点不支持等待队列功能)
• 这些旧节点可能不会发送必要的探测(probes)，从而导致上述崩溃

影响范围

这个问题主要影响以下场景：

1. 从低于2024.1的版本升级到2024.1或更高版本的用户
2. 在升级过程中，当集群处于混合版本状态时
3. 涉及事务冲突和死锁检测的场景

解决方案

虽然相关修复已经包含在2024.2.0.0版本中，但用户报告在2024.2.2.2-b2版本中仍然遇到此问题。需要注意的是：

1. 这个问题只会在升级过程中短暂出现
2. 一旦升级完成，所有节点都运行在支持等待队列的版本上，问题将不再出现
3. 对于生产环境，建议在升级期间做好监控，并准备好回滚方案

最佳实践

对于计划升级的用户，建议：

1. 在非高峰期执行升级操作
2. 监控升级过程中的事务处理情况
3. 确保升级过程尽可能快速完成，减少集群处于混合版本状态的时间
4. 考虑先在测试环境中验证升级过程

总结

YugabyteDB在2024.1版本引入的等待队列功能虽然提升了事务处理能力，但在升级过程中可能会因为版本不一致导致段错误问题。开发团队已经意识到这个问题，并建议用户在升级过程中注意监控，一旦升级完成，问题将自然解决。对于关键业务系统，建议在升级前充分测试并制定详细的升级计划。