检查点、恢复和交付语义

了解数据流配置的检查点、恢复和交付。

`pos` 公共合同

默认情况下，每个非元数据 DML 或 DDL 记录都包含不透明的 pos 标记。在内部，令牌具有足够的 GoldenGate 定位信息来标识记录，包括提交或序列信息、事务处理标识和记录排序。它的编码不是公共源协调格式，并且可能因源类型和发行版而异。

执行	不
成功处理后存储确切的字符串。	对其进行语法分析以获取 Oracle SCN、PostgreSQL LSN、MySQL binlog 坐标、SQL Server LSN 或任何其他特定于源的偏移量。
将其范围限定为数据流、源线索合同和消费者。	按词汇或数字比较职位以确定顺序。
在 URL 中用作 `begin` 时对其进行百分比编码。	修剪、规范化、连接、解密或重写它。
使用单独的 `csn`、`xid`、`opSeqno` 和 `transInd` 字段进行诊断或事务分析。	重用来自其他流、其他筛选器合同或其他环境的位置。

源可移植性：对于 Oracle、PostgreSQL、MySQL、SQL Server 和其他受支持的源，客户机恢复算法有意相同：保留不透明的 pos 并使其保持不变。Data Streams 客户端合同既不要求也不支持特定于源的坐标分析。

检查点必须表示其业务影响持久的最后一条记录。在业务写入之前保存可能会在崩溃后丢失数据。在单独的事务中非幂等写入后保存可能会在崩溃后生成重复项。

模式	工作方式	使用时间
原子接收器和检查点事务处理	在同一数据库事务处理中编写业务记录和新 `pos`。	sink 和 checkpoint 可以共享事务数据存储。
幂等键	使用 `pos` 或业务关键字加操作标识作为唯一关键字；重试同一记录将变为无操作。	sink 支持唯一性或条件写入。
持久暂存日志	将记录和 `pos` 以原子方式附加到持久日志，然后独立处理日志。	业务处理速度慢、涉及多个步骤或跨多个系统。
通过对账至少一次	接受重复项，定期删除重复项，并核对盘点或校验和。	该用例允许最终更正。

注意：数据流 exactlyOnce 介绍了服务端重复隐藏和恢复响应。它不会只产生一次任意下游副作用，因为 WebSocket 协议没有与客户机进行每记录事务确认。

请参见下表中的服务质量准则：

模式	复制	保存的职位不可用	推荐使用
`exactlyOnce`	隐藏在恢复和源线索重新启动/异常终止处理期间识别的重复项。	连接失败，出现错误。	持久业务处理的默认值。与原子或幂等的消费者逻辑配对。
`atLeastOnce`	在恢复和源线索重新启动/异常终止处理期间不隐藏重复项。	连接失败，出现错误。	当首选重放并且使用者设计为删除重复项时使用。
`atMostOnce`	隐藏已识别的重复项。	服务将查找下一个可用记录并继续，这可能会跳过数据。	仅当数据丢失是显式可接受的，并且正向进度比完整性更重要时才使用。

有关事务处理元数据和排序要求，请参阅下表：

字段	用途	限制
`xid`	对与源事务处理关联的记录进行分组。	格式与源相关，应视为字符串。
`csn`	配置时公开来源提交序号。	含义和格式取决于源；不要用作重新启动令牌。
`opSeqno`	记录事务处理中的序号。	启用并（可选）显式重命名。
`transInd`	`B` first、`M` middle、`E` last 或 `W` whole/single-operation transaction。	筛选可以删除记录，并使观察到的序列不完整。协调处理也会降低使用率。
`pos`	记录的唯一恢复位置。	不透明；请勿从事务处理文本中排序或推导事务处理边界。

不要假定连接始终从事务处理边界开始。在较早的操作不再可用后，可以开始时间戳查找或保留线索边界。如果应用程序需要完整的源事务处理，请设计事务处理缓冲区，定义大型事务处理的限制，并指定在事务处理开始不可用时应执行的操作。

要检查变为不可用状态的已保存职位，请检查以下各项：

确认检查点属于同一数据流、源线索以及筛选器/输出合同。
确认该值已进行百分比编码而不进行更改。
确认尚未清除包含该职位的线索段。
使用 exactlyOnce 或 atLeastOnce 时，将错误视为恢复意外事件。恢复线索历史记录，选择批准的时间戳或最早位置，并在恢复之前调节下游状态。
使用 atMostOnce 时，服务可以在下一个可用记录处继续。记录产生的数据差距并执行业务批准的对账过程。

将线索保留设置为超过恢复点目标以及操作检测和响应时间。例如，如果使用者可以脱机 24 小时，并且事件响应需要 12 小时，则需要 36 小时以上的可用线索，并且存在大量积压和维护的额外保证金。bufferSize 不会延长线索保留期。