Neon数据库存储清理器测试中的稳定性问题分析

背景介绍

Neon数据库是一个云原生数据库系统，其存储子系统包含多个组件协同工作。在最近的一次测试中，开发团队发现test_scrubber_tenant_snapshot[4]测试用例存在不稳定的问题，表现为测试过程中出现"request was dropped before completing"的错误。

问题现象

测试过程中主要观察到三种异常现象：

1. 测试日志中出现"request was dropped before completing"错误信息
2. 本地测试时频繁出现"unsupported command START_WAL_PUSH in START_WAL_PUSH"错误
3. 存储控制器(storcon)日志中先出现"Shared lock by TimelineCreate was held for..."警告，随后才出现请求被丢弃的错误

问题根因分析

经过深入调查，开发团队确定了问题的根本原因：

1. 测试环境残留问题：本地测试时发现的"START_WAL_PUSH"错误和锁持有时间过长的警告，实际上是由于前次测试的残留进程未完全清理导致的，与当前测试问题无关。

2. 分布式协调问题：测试中会重启所有页面服务器(pageserver)，但由于重启操作不是原子性的，存储控制器可能会在此期间迁移部分分片(shard)。当所有页面服务器重新上线后，分片分布可能不均衡，某些节点可能没有分片，而其他节点则拥有多个分片。

3. 资源竞争问题：测试执行与后台的协调(reconciliation)过程同时进行，在测试结束时，存储控制器会先停止，导致所有正在进行的协调请求(如heatmap_upload和secondary/download)被取消，从而触发页面服务器记录"request was dropped before completing"的警告日志。

解决方案

针对上述问题，开发团队采取了以下改进措施：

1. 测试流程优化：在测试结束时，显式设置适当的分片调度策略，并等待所有协调操作完成，确保系统状态稳定后再进行清理。

2. 错误处理改进：将这类"请求被丢弃"的日志消息标记为噪音信息，在测试验证时予以忽略，因为这些错误实际上是测试流程本身导致的预期行为，而非系统真实问题。

验证结果

改进后的测试表现：

1. 在多次并行测试运行中，失败率显著降低
2. 虽然偶尔仍会出现存储控制器的请求被丢弃警告，但已不再影响测试结果
3. 其他相关错误(如分片拆分后的secondary download调用错误、NotFound异常等)出现频率也大幅降低

经验总结

这个案例揭示了分布式系统测试中的几个重要经验：

1. 原子性操作的重要性：在涉及多节点协调的操作中，必须考虑操作的原子性，避免中间状态导致系统行为不一致。

2. 测试环境隔离：确保每次测试都有干净的初始环境，避免残留状态影响测试结果。

3. 预期错误处理：对于测试流程本身导致的预期错误，应该明确区分并适当处理，而不是将其视为系统缺陷。

4. 分布式系统测试的特殊性：在分布式环境中，组件间的时序和协调更加复杂，测试设计需要考虑更多边界情况。

通过这些改进，Neon数据库的存储清理器测试稳定性得到了显著提升，为系统的可靠性提供了更好保障。