操作和监视数据流

GoldenGate 端监视

• 确认数据流资源在分发服务中存在且可用。

• 监视 UI 或服务度量公开的记录和发送的字节数、操作计数、DDL 计数、表活动和网络统计信息。

• 复核分配服务日志以了解验证、线索查找、位置查找、方案生成、大小截断和 WebSocket 断开错误。

• 独立监视源提取和线索生成。健康的 WebSocket 无法提供未到达线索的数据。

使用者指标

度量	为什么很重要
连接状态和重新连接计数	检测网络、验证、代理和服务不稳定性。
上次收到和上次提交日期 pos	将数据到达与成功持久处理分开。如果位置被视为敏感，则记录散列值或受保护值。
按类型/表列出的记录和字节	标识意外的卷、过滤错误和偏差。
处理延迟	从 op_ts 到持久下游提交的时间。来源和消费者时钟差异。
内部队列深度和最早排队时间	在内存耗尽之前检测背压。
方案/元数据版本更改	检测 DDL 和合同更改。
重复和幂等冲突计数	验证传送和检查点行为。
死信和验证失败	显示需要手动或自动补救的记录。

缓冲区和容量规划

bufferSize 控制服务将其内存中消息队列刷新到客户机的字节阈值。更大的值可以提高批处理效率，但可以增加每消息的内存使用和延迟。较小的值可以减少延迟，但会增加消息开销。它不是一个持久的队列，不会替换轨迹保留，也不会消除对消费者背压控制的需求。

• 使用代表性事务处理大小、LOB、DDL、表计数和峰值吞吐量进行测试。

• 将 WebSocket 和代理最大消息大小设置为高于预期的最大批处理。

• 使用有边界队列并快速失败，而不是允许无边界的内存增长。

• 分别进行网络接收、验证、下游 I/O 和检查点提交，以便可以测量每个阶段。

重新连接策略

• 从最后一个持久检查点（而不是上次仅接收的记录）重新连接。

• 使用指数回退，最大延迟和抖动。

• 在稳定连接后重置延迟。

• 对不可重试的故障（例如身份证明无效或保存的职位不可用）进行分类，并引发操作员警报，而不是永久重试。

• 在恢复期间保留相同的输出合同。如果流配置已更改，请在恢复之前完成兼容性验证。

多个使用方

数据流不提供 Kafka 风格的使用者组或服务器管理的每使用者偏移量。每个独立客户机必须维护自己的检查点，并根据其连接和 begin 值接收记录。请勿在并发活动使用者之间共享一个检查点，除非外部协调者保证单个所有权并订购了检查点更新。

变更管理

• 对数据流配置进行版本控制，并使用使用者发行版生成 AsyncAPI YAML。

• 测试创建、连接、稳定状态处理、断开连接、重新启动、保留位置故障、DDL、大型记录和凭证轮换。

• 在启用新的有效负载字段或模式更改之前，请部署兼容的使用者代码。

• 保留一个回退计划，该计划保留最后一个已知良好的检查点和配置。