Apache Doris间歇性查询报错[E-230]missed_versions is empty的排查与解决

根因定位方向 #

• 版本保留窗口不足：查询执行时间超过BE配置的旧版本保留时长，导致执行过程中需要的版本被清理
• 版本清理策略激进：BE的版本清理相关参数设置过小，旧版本被过早删除
• 数据版本迭代过快：大表频繁进行导入、合并操作，版本生成速度远超查询执行速度
• 查询执行延迟：复杂查询的计划生成或分片扫描耗时过长，等到扫描某分片时对应版本已被清理

具体解决方案 #

1. 调整BE版本保留相关参数 #

修改BE节点的conf/be.conf文件，调整以下参数后重启BE：

• 增大min_version_reserved_sec：设置为足够覆盖最长查询执行时间的值，比如从默认的3600（1小时）调整为7200（2小时）或更高
• 增大delete_expired_version_interval_sec：延长版本清理的检查间隔，避免过于频繁清理，比如从默认的600（10分钟）调整为1800（30分钟）
• 临时关闭自动合并（仅用于定位）：设置disable_auto_compaction=true，验证是否因频繁合并导致版本快速迭代（注意：长期关闭会影响查询性能，定位后需恢复）

2. 优化查询语句 #

• 减少扫描数据量：通过分区过滤、预聚合、合理使用前缀索引等方式缩短查询执行时间
• 拆分复杂查询：将单条长时查询拆分为多个短查询，降低单查询的执行时长，避免超过版本保留窗口
• 错峰执行查询：选择业务低峰期运行分析类查询，减少导入/合并操作对数据版本的影响

3. 调整表的合并策略 #

• 优化大表合并规则：对频繁导入的大表，设置compaction_policy=BASE_COMPACT或调大合并触发阈值，减少小版本的生成频率
• 手动触发合并：在业务低峰期执行ALTER TABLE table_name COMPACT，提前合并旧版本，降低版本数量

4. 集群层面优化 #

• 监控版本变化：通过FE WebUI（默认8030端口）查看BE节点的版本统计，定位版本迭代过快的表
• 均衡节点负载：调整分片分布，确保各BE节点负载均匀，避免因节点负载过高导致查询执行延迟
• 升级Doris版本：2.1.2版本存在部分版本匹配逻辑的已知问题，升级到最新稳定版（如2.5.x）可修复相关bug

验证方法 #

• 运行之前频繁报错的复杂查询，观察是否仍出现[E-230]missed_versions is empty报错
• 查看BE节点be.INFO日志，确认旧版本清理时间符合预期
• 统计查询执行时长，确保其小于min_version_reserved_sec设置的值

内容的提问来源于stack exchange，提问作者Michael