Apache Pegasus 中副本服务器重启导致断言失败的故障分析

问题背景

在分布式存储系统 Apache Pegasus 中，数据同步（duplication）是一个重要功能，它允许将数据从一个集群同步到另一个集群。然而，在某些特定场景下，当副本服务器在数据同步过程中重启时，系统会出现断言失败导致进程异常退出的问题。

问题现象

当配置两个 Pegasus 集群（集群 A 和集群 B）进行数据同步时，如果满足以下条件：

1. 集群 A 配置为无认证模式且仅包含一个节点
2. 集群 B 配置为认证模式且包含三个节点
3. 在集群 A 上创建表并启动全量数据同步
4. 由于集群 B 的认证机制，同步状态停留在 DS_PREPARE
5. 此时重启集群 A 的唯一副本服务器

服务器重启后会立即触发断言失败并退出，错误日志显示：

assertion expression: min_checkpoint_decree > 0
F2024-08-16 16:08:56.33 -1 vs 0 min_checkpoint_decree should be a number greater than 0 which means a new checkpoint must be created

技术分析

数据同步状态机

Pegasus 的数据同步过程包含多个状态：

• DS_PREPARE：准备阶段，通常用于创建远程表或初始化同步环境
• DS_APP：正常同步阶段
• DS_LOG：日志同步阶段

在 DS_PREPARE 状态下，系统需要为全量同步创建检查点（checkpoint）。

问题根源

当副本服务器重启时，系统会重新初始化所有同步器（replica_duplicator）。对于处于 DS_PREPARE 状态的同步任务，系统会尝试触发手动紧急检查点。然而，重启后 min_checkpoint_decree 被错误地重置为无效值（-1），而系统断言要求该值必须大于 0。

设计缺陷

问题的本质在于状态恢复逻辑不完善：

1. 对于已经存在的同步任务，重启后应该恢复其之前的状态
2. DS_PREPARE 状态的任务需要继续完成检查点创建
3. 当前实现错误地将所有任务的 min_checkpoint_decree 重置，而没有考虑不同状态的差异

解决方案

修复方案需要确保：

1. 重启后正确恢复同步任务的检查点状态
2. 对于 DS_PREPARE 状态的任务，保持其 min_checkpoint_decree 的有效性
3. 只有当确实需要创建新检查点时，才要求 min_checkpoint_decree > 0

总结

这个案例展示了分布式系统中状态恢复的重要性。在 Pegasus 的数据同步功能中，需要特别注意不同同步状态下的恢复逻辑差异。通过修复这个问题，提高了系统在异常情况下的健壮性，确保了数据同步过程的可靠性。

对于使用 Pegasus 的开发者和运维人员来说，理解系统在不同状态下的行为对于故障排查和系统维护至关重要。特别是在涉及认证、跨集群同步等复杂场景时，需要格外关注状态转换和恢复逻辑。