Typesense集群磁盘使用不一致问题的分析与解决

问题背景

在使用Typesense构建的3节点搜索集群中，运维人员遇到了一个棘手的问题：不同节点间的磁盘使用情况存在显著差异，导致容器频繁因磁盘空间不足而崩溃。特别是在使用Typesense-docsearch-scraper工具定期更新索引时，这一问题尤为明显。

问题表现

集群运行在Docker容器中，每个节点分配了10GB的持久化存储空间。主要症状包括：

1. 容器频繁崩溃，日志显示"Write to disk failed"错误
2. 崩溃前出现大量"lagging entries"警告日志
3. 各节点磁盘使用模式差异巨大：
   • 节点0：1.1GB使用量，主要存储在state/snapshot目录
   • 节点1：5.7GB使用量，同样主要在state/snapshot目录
   • 节点2：7.6GB使用量，主要存储在db目录

技术分析

Typesense的数据存储机制采用了两层结构：

1. db目录：存储实际的索引数据
2. state目录：包含raft日志和快照

在数据写入时，Typesense会同时写入raft日志和db目录。每小时会执行一次快照操作，通过硬链接方式将db目录内容链接到state/snapshot目录。这种设计理论上应该保持两个目录的数据量基本一致。

问题根源

经过分析，这个问题主要源于：

1. 版本缺陷：v0.25.2版本在处理频繁创建和删除集合的操作时存在磁盘空间回收问题
2. 快照机制：当大量写入发生在快照周期之间时，会导致db目录和快照目录数据量不一致
3. 磁盘类型：使用AWS EBS GP3块存储可能影响硬链接的性能表现

解决方案

Typesense开发团队在v26.0版本中针对此问题进行了优化，具体改进包括：

1. 优化了频繁创建和删除集合场景下的磁盘空间管理
2. 引入了新的配置参数db-compaction-interval，建议设置为21600秒(6小时)
3. 改进了快照机制，确保更稳定的磁盘使用模式

实施效果

升级到v26.0并调整配置后：

1. 各节点磁盘使用量趋于一致，稳定在1.5-1.6GB范围
2. 崩溃问题完全消失
3. 虽然各节点存储分布仍有差异(db目录与state/snapshot目录)，但这属于正常现象，不影响系统稳定性

最佳实践建议

对于类似场景的用户，建议：

1. 使用v26.0或更高版本
2. 合理设置db-compaction-interval参数
3. 监控各节点的磁盘使用情况
4. 为每个节点预留足够的磁盘空间缓冲(建议至少20%余量)
5. 定期检查日志中的raft相关警告信息

通过这次问题的解决，我们不仅修复了磁盘使用异常的问题，也更加深入理解了Typesense的存储机制，为后续的运维工作积累了宝贵经验。