YugabyteDB CDC 生产者安全时间机制问题分析

问题概述

在 YugabyteDB 版本 2.25.2.0-b329 中，CDC (Change Data Capture) 功能在处理事务负载时存在一个关键问题：CDC 生产者错误地使用了 tablet leader 的安全时间而非一致的流安全时间作为基准。这一设计缺陷在提高 GetChanges 调用频率的情况下，可能导致数据丢失问题。

技术背景

YugabyteDB 的 CDC 功能通过捕获数据库变更并将其发送到外部系统来实现数据复制。在这个过程中，安全时间(Safe Time)机制至关重要，它决定了哪些数据变更可以被安全地发送而不会导致数据一致性问题。

在 YugabyteDB 中，存在两种不同类型的安全时间：

1. Tablet Leader 安全时间：单个 tablet leader 节点维护的安全时间，仅反映该节点上的数据状态
2. 一致的流安全时间：跨多个 tablet 的全局一致的安全时间，确保所有相关 tablet 的数据变更都已准备好

问题根源

当前实现中，CDC 生产者在处理事务负载时错误地依赖了 tablet leader 的安全时间而非一致的流安全时间。这种选择会导致以下问题：

1. 数据可见性不一致：当系统处于高负载状态时，单个 tablet 的安全时间可能无法准确反映整个分布式系统的全局状态
2. 数据丢失风险：在提高 GetChanges 调用频率的情况下，这种不一致会被放大，可能导致部分变更记录被跳过或丢失
3. 复制停滞：在某些情况下，这种不一致会导致复制过程停滞，如报告中提到的"Change is the same for 30 minutes"错误

影响分析

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

1. 高频率变更捕获：当 CDC 消费者频繁调用 GetChanges 接口时
2. 分布式事务：涉及多个 tablet 的跨分区事务
3. 高负载环境：系统处理大量并发事务时

在测试案例中，这一问题表现为源数据库(yb=107234)和接收端(sink=107225)之间的数据不一致，复制过程在特定时间点停止。

解决方案建议

要解决这一问题，需要对 CDC 生产者的安全时间选择机制进行修改：

1. 统一使用一致的流安全时间：在所有情况下都应优先使用全局一致的流安全时间
2. 增加一致性检查：在获取变更前验证各 tablet 的状态一致性
3. 优化安全时间传播机制：确保流安全时间能够及时准确地反映系统状态

总结

YugabyteDB CDC 功能中错误的安全时间选择机制是一个需要高度重视的问题，特别是在高频率变更捕获和分布式事务场景下。修复这一问题将显著提高 CDC 功能的可靠性和数据一致性保证。

对于使用受影响版本(2.25.2.0-b329)的用户，建议关注该问题的修复进展，并在生产环境中谨慎使用高频率的 GetChanges 调用。在问题修复前，可以考虑适当降低变更捕获频率作为临时解决方案。