Apache Pegasus手动压缩任务进度检测问题解析

问题背景

在Apache Pegasus分布式存储系统中，手动压缩(manual compact)是一个重要的维护操作，用于优化数据存储结构。系统提供了pegasus_manual_compact.sh脚本来执行这一操作，其中包含一个wait_manual_compact()函数用于监控压缩任务的执行进度。

问题现象

用户在使用pegasus_manual_compact.sh脚本执行手动压缩时发现，即使压缩任务已经完成，wait_manual_compact()函数仍持续输出"[35s] 0 finished, 8 not finished"的日志信息，无法正确识别任务已完成的状态。这导致在封装手动压缩工具时，基于该函数输出的进度判断会出现超时失败的情况。

技术分析

命令输出格式变更

问题的根本原因在于remote_command -t replica-server replica.query-compact ${app_id}命令的输出格式发生了变化：

旧版本输出格式示例：

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 [-]
...

新版本输出格式示例：

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":"-"}
...

解析逻辑失效

wait_manual_compact()函数原本的解析逻辑是基于旧版本的文本格式设计的，当输出变为JSON格式后，原有的字符串匹配逻辑无法正确识别压缩任务的完成状态。具体表现为：

1. 无法正确解析"last_finish"字段
2. 无法识别已完成和未完成的分区
3. 无法计算剩余时间估计

影响范围

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

1. 自动化运维系统中基于脚本输出判断压缩进度的功能
2. 长时间运行的压缩任务监控
3. 依赖压缩完成状态触发的后续操作

解决方案建议

针对此问题，建议从以下几个方面进行改进：

1. 更新解析逻辑：修改wait_manual_compact()函数，使其能够正确解析JSON格式的输出，特别是"last_finish"等关键字段。

2. 增加版本兼容性：在脚本中增加对两种输出格式的识别，保持向后兼容。

3. 完善状态判断：除了检查"last_finish"字段外，还应考虑"recent_start_at"等字段，提供更精确的进度判断。

4. 增强错误处理：对于无法解析的输出格式，应给出明确的警告信息而非错误的状态判断。

技术实现示例

以下是改进后的解析逻辑伪代码示例：

parse_compact_status() {
    local output="$1"
    
    # 尝试解析JSON格式
    if [[ $output == *"{"*"}"* ]]; then
        # 提取JSON部分并解析
        local json_part=$(extract_json "$output")
        local finish_time=$(parse_json_field "$json_part" "last_finish")
        # 其他字段处理...
    else
        # 旧版文本格式处理
        # 原有解析逻辑...
    fi
}

总结

Apache Pegasus系统中手动压缩任务的进度检测问题源于底层命令输出格式变更导致的解析逻辑失效。通过更新解析逻辑、增强格式兼容性，可以解决这一问题，确保自动化运维流程的可靠性。这也提醒我们在设计运维工具时，需要考虑接口变更的兼容性问题，建立完善的版本适应机制。