GreptimeDB表结构变更引发的查询崩溃问题分析

在分布式时序数据库GreptimeDB的使用过程中，我们发现了一个与表结构变更相关的严重问题。当用户先对表设置TTL属性，再添加新列后执行查询操作时，会导致数据库服务崩溃。这个问题不仅影响数据查询功能，还会造成客户端连接中断，对生产环境构成严重威胁。

问题现象重现

通过标准MySQL协议连接到GreptimeDB后，按照以下步骤可以稳定复现该问题：

1. 创建基础表结构：包含一个整型列和一个时间索引列
2. 插入测试数据
3. 为表设置TTL(生存时间)属性
4. 添加一个新的字符串列并设置默认值
5. 执行查询操作时服务崩溃

特别值得注意的是，崩溃发生在看似简单的SELECT查询阶段，而非表结构变更阶段，这使得问题更具隐藏性。

技术原理分析

从错误日志中可以清晰地看到，崩溃发生在Arrow Schema的索引越界访问。具体来说，当DataFusion执行引擎尝试构建查询计划时，Schema的字段索引访问超出了实际字段数量。这表明表结构变更后的元数据与实际存储结构出现了不一致。

深入分析可知，GreptimeDB在内部使用Arrow格式存储数据，而TTL设置和列添加操作都会影响表的元数据表示。当这两个操作连续执行时，可能导致Schema版本管理出现问题，使得查询引擎获取到的Schema与实际数据不匹配。

影响范围评估

该问题主要影响以下场景：

• 使用ALTER TABLE修改表属性后立即添加新列
• 任何包含TTL设置的时序表结构变更
• 通过MySQL协议执行的查询操作

由于崩溃发生在查询阶段，这意味着已经写入的数据不会丢失，但服务不可用期间新的写入请求会失败。

解决方案建议

针对这类问题，建议从以下几个方向进行修复：

1. Schema版本一致性检查：在执行查询前验证Schema与数据的兼容性
2. 操作序列化处理：将表结构变更操作串行化，避免并发修改导致状态不一致
3. 元数据持久化机制：确保TTL设置和列添加操作的原子性
4. 查询计划缓存失效：在表结构变更后主动清除相关查询计划缓存

最佳实践

为避免类似问题，建议用户在进行表结构变更时：

1. 避免在同一个事务中混合表属性修改和列增减操作
2. 复杂表结构变更分步执行，每一步后验证表状态
3. 生产环境变更前先在测试环境验证
4. 监控表结构变更操作的执行状态

该问题的发现凸显了数据库系统中元数据管理的重要性，特别是在支持多种表属性组合的场景下。GreptimeDB团队已确认该问题并在后续版本中修复，建议用户及时升级到最新稳定版本。