Tarantool中二级索引在WAL回滚后丢失元组的问题分析

问题背景

在Tarantool数据库系统中，当使用Vinyl存储引擎并启用延迟删除(deferred DELETE)功能时，如果遇到WAL(Write-Ahead Log)回滚情况，可能会导致非唯一二级索引中的元组丢失。这是一个严重的数据一致性问题，会影响系统的可靠性。

问题现象

在特定场景下，当满足以下条件时会出现问题：

1. 对一个带有非唯一二级索引的空间执行DELETE操作
2. 启用了延迟删除功能(vinyl_defer_deletes=true)
3. 操作因WAL错误而回滚
4. 在操作未确认期间，另一个纤程从二级索引读取了包含被删除键的区间

此时，回滚后通过二级索引查询会发现该元组"消失"了，而实际上主键索引中该元组仍然存在。

技术原理分析

延迟删除机制

延迟删除是Vinyl引擎的一项优化功能，它允许将DELETE操作推迟到压缩时执行，而不是立即从索引中移除数据。这样可以减少写放大，提高性能。

问题根源

问题的核心在于二级索引的元组缓存(tuple cache)在WAL回滚时没有被正确失效。具体来说：

1. 启用延迟删除后，提交时不会向二级索引写入任何内容
2. 当WAL回滚发生时，系统缺乏有效手段来使二级索引的缓存失效
3. 导致缓存中仍然保留着"已删除"的状态信息
4. 后续查询会错误地认为该元组已被删除

影响范围

该问题影响以下版本：

• 2.11.x系列
• 3.2.x系列
• 3.3.x系列

解决方案

开发团队通过以下方式解决了这个问题：

1. 修改了缓存失效机制，确保在WAL回滚时正确失效二级索引缓存
2. 增加了相关测试用例，验证修复效果
3. 通过多个提交逐步完善修复方案

临时规避措施

在修复版本发布前，用户可以通过以下方式规避此问题：

1. 禁用元组缓存：设置vinyl_cache = 0
2. 关闭延迟删除功能：不设置vinyl_defer_deletes或设为false

技术启示

这个问题揭示了分布式系统中数据一致性的复杂性，特别是在涉及：

• 多级索引维护
• 延迟操作优化
• 事务回滚处理
• 并发访问控制

开发者在设计类似系统时，需要特别注意这些边界条件下的数据一致性保证。同时，这也体现了完善的错误注入测试在数据库系统开发中的重要性。