Hightouch团队在10月20日AWS故障后尝试扩容事件处理系统时，意外发现Aurora RDS存在竞态条件漏洞。该问题后被AWS确认，文章分享了他们如何诊断这个AWS系统级错误的过程和经验。

我们如何发现Aurora RDS中的竞态条件

背景

2025年10月20日，AWS在us-east-1区域因DNS管理服务中的竞态条件故障导致大规模服务中断。Hightouch Events产品（用于收集用户行为数据）在此次事件中积压了大量待处理数据，促使我们决定在10月23日升级Aurora RDS实例规格以提升处理能力。

技术架构

Hightouch事件系统采用三层架构： 1. Kubernetes集群运行事件收集器和批处理工作节点 2. Kafka处理事件流 3. PostgreSQL（Aurora版）作为虚拟队列元数据存储

在10月20日的AWS中断期间，我们观察到： - 服务无法连接AWS MSK管理的Kafka代理 - 因EC2节点无法扩容导致服务自动扩展失败 - 实时数据转换功能因AWS STS错误而失效

升级计划

我们设计的分阶段升级方案： 1. 新增临时读副本（实例#3） 2. 升级现有读副本（实例#2）并设为最高故障转移优先级 3. 触发故障转移将实例#2提升为写入节点（预期中断<15秒） 4. 升级原写入节点（实例#1）为读副本 5. 移除临时读副本

故障现象

2025年10月23日16:39（EDT），首次故障转移尝试出现异常： - AWS控制台显示实例#2短暂提升后，写入权限又回退到实例#1 - 后端服务出现"cannot execute UPDATE in a read-only transaction"错误 - 5分钟内两次故障转移均失败

问题排查

通过分析日志和指标发现： 1. 数据库日志显示两个实例同时收到写入请求 2. 存储层拒绝并发写入导致双实例崩溃 3. 故障转移期间存在竞态条件：旧写入节点降级与新写入节点升级未同步完成

解决方案

验证性测试证实： - 停止所有写入服务后，故障转移成功完成 - AWS确认这是其内部信号处理缺陷，与客户配置无关 - 临时解决方案：故障转移前暂停所有写入操作

经验总结

1. 关键操作需准备回退方案，即使对可信服务也应如此
2. 完善的监控体系（如Datadog指标+RDS日志）对快速定位问题至关重要
3. 分布式系统设计需考虑组件隔离，避免单点故障影响全局
4. 测试环境可能无法复现生产环境的特殊条件

（注：文中所有时间标记为原文设定的2025年未来时间）

总结评论内容：

1. 对Aurora故障转移机制的质疑（评论2,4,7,8）

• "手动故障转移在写入流量下会失败"（评论2）
• "这正是我希望Aurora能维护的基本功能，毕竟我们付了那么多钱"（评论4）
• "AWS已表示会修复，但当前建议在故障转移期间停止写入"（评论7）

2. Aurora架构的积极评价（评论5）

• "计算与存储分离的架构很有吸引力，类似MSSQL的超大规模方案"（评论5）

3. 性能与成本的比较（评论3）

• "不需要多可用区时，RDS+gp3可能比Aurora性能更好且更便宜"（评论3）
• "Aurora插入速度慢，基准测试缺乏RDS配置细节难以信服"（评论3）

4. 扩展性警告（评论1）

• "通过只读副本扩展是危险的做法，只能扩展系统特定部分"（评论1）

5. 用户共鸣（评论6,8）

• "很高兴知道不是我一个人遇到这个问题"（评论6）
• "我们经常在高压环境下执行类似操作都没问题"（评论8）

6. 标题建议（评论9）

• "标题应该加上postgres"（评论9）