Pegasus项目中手动压缩任务进度检测问题分析

问题背景

在分布式存储系统Pegasus中，手动压缩(manual compact)是一个重要的维护操作，用于优化数据存储结构。然而，近期发现pegasus_manual_compact.sh脚本中的wait_manual_compact()函数无法正确检测手动压缩任务的执行进度，导致在封装手动压缩工具时出现超时失败的问题。

问题现象

当使用命令sh pegasus_manual_compact.sh -c {meta_server_list} -a {table_name} --bottommost_level_compaction force执行手动压缩时，wait_manual_compact()函数会持续输出类似日志：

[35s] 0 finished, 8 not finished (0 in queue, 0 in running), estimate remaining unknown seconds. table [**] manual compaction is running now.

即使手动压缩任务已经完成，该函数仍会持续输出上述信息，无法正确判断任务是否真正完成。

根本原因分析

经过深入调查，发现问题的根源在于wait_manual_compact()函数无法正确解析remote_command -t replica-server replica.query-compact ${app_id}命令的输出格式变化。

在Pegasus的早期版本中，该命令输出格式为：

CALL [replica-server] [10.1.132.36:8171] succeed: 8 processed, 0 not found
4.0@10.1.132.36:8171@P : last finish at [-]
4.1@10.1.132.36:8171@P : last finish at [-]
4.2@10.1.132.36:8171@P : last finish at [-]
...

而在最新版本中，输出格式已变更为更详细的JSON格式：

CALL [replica-server] [10.1.132.34:8171] succeed:
8 processed, 0 not found
4.0@10.1.132.34:8171@P : {"last_finish":"-","last_used_ms":"-","recent_enqueue_at":"-","recent_start_at":"-"}
4.1@10.1.132.34:8171@P : {"last_finish":"-","last_used_ms":"-","recent_enqueue_at":"-","recent_start_at":"-"}
...

技术影响

1. 自动化流程中断：由于进度检测失败，依赖此功能的自动化运维流程会出现异常中断
2. 运维效率降低：管理员需要手动确认任务状态，增加了运维复杂度
3. 资源浪费：系统可能重复执行已完成的任务，造成不必要的资源消耗

解决方案建议

1. 输出格式适配：更新wait_manual_compact()函数，使其能够同时兼容新旧版本的输出格式
2. JSON解析增强：对于新版输出，应增加JSON解析逻辑，准确提取关键状态信息
3. 状态判断优化：基于更丰富的状态信息（如recent_start_at等），实现更精确的任务状态判断
4. 兼容性处理：在变更期间应保持对旧版本的支持，确保平滑过渡

总结

Pegasus作为分布式存储系统，其手动压缩功能对系统性能优化至关重要。此问题的解决不仅能够修复当前的功能缺陷，还能为后续类似的功能扩展提供参考。建议在修复此问题时，同时考虑增加更丰富的状态监控指标，为系统运维提供更全面的可视化支持。