Pegasus 分布式存储系统中的全量复制卡顿问题分析

问题背景

在分布式存储系统 Pegasus 中，全量复制(duplication)功能允许用户将一个表的数据完整复制到另一个集群。这一功能在实际应用中非常重要，可以实现数据备份、跨机房容灾等场景。然而，在某些情况下，复制过程可能会在准备阶段(DS_PREPARE)卡住，导致复制任务无法继续进行。

问题现象

在最近的运维过程中，我们发现一个全量复制任务在创建后一直停留在 DS_PREPARE 状态，无法进入后续阶段。通过分析系统日志，发现以下关键信息：

1. 源集群主控节点成功创建了复制任务，但状态停留在 DS_PREPARE
2. 在尝试创建目标集群的跟随者表时，出现了 ERR_TIMEOUT 错误
3. 后续重试时又出现了 ERR_APP_EXIST 错误，表明表已存在但复制流程未正常推进

深入分析

复制流程机制

Pegasus 的全量复制流程大致分为以下几个阶段：

1. DS_INIT：初始化阶段
2. DS_PREPARE：准备阶段，主要工作是创建目标表并准备检查点
3. DS_APP：应用阶段，开始实际数据复制
4. DS_LOG：日志复制阶段

在准备阶段，系统需要完成以下关键操作：

• 在目标集群创建对应的跟随者表
• 从源集群获取检查点数据
• 将检查点数据传输到目标集群

问题根源

从日志分析可以看出，问题发生在准备阶段的表创建和检查点准备环节：

1. 源集群向目标集群发送创建表的请求，但由于网络或安全策略原因，请求超时(ERR_TIMEOUT)
2. 源集群重试时，发现表已存在(ERR_APP_EXIST)，但此时复制流程已经处于不一致状态
3. 目标集群虽然创建了表结构，但由于无法连接到源集群获取检查点数据，导致副本初始化失败

特别值得注意的是，目标集群的副本服务器在尝试连接源集群获取检查点数据时失败，这与源集群的安全策略有关，导致整个复制流程无法继续。

解决方案

针对这一问题，Pegasus 开发团队已经提交了修复方案，主要改进包括：

1. 增强复制流程的状态管理机制，确保在遇到错误时能够正确恢复
2. 改进错误处理逻辑，特别是对 ERR_APP_EXIST 这种情况的特殊处理
3. 增加更详细的日志记录，便于问题诊断
4. 优化超时机制和重试策略

最佳实践建议

对于使用 Pegasus 复制功能的用户，我们建议：

1. 确保源集群和目标集群之间的网络连通性，特别是安全策略不会阻止必要的通信
2. 监控复制任务的状态，及时发现并处理卡住的任务
3. 定期检查系统日志，关注复制相关的警告和错误信息
4. 在重要业务场景中，考虑实现自定义的监控和告警机制

总结

Pegasus 的全量复制功能虽然强大，但在复杂的网络环境和安全策略下可能会遇到各种问题。通过深入分析日志和系统行为，我们不仅解决了当前的问题，还改进了系统的健壮性。对于分布式存储系统来说，处理网络分区和各种异常情况是设计中的永恒主题，需要持续优化和改进。