同步表更新逻辑说明
1. 概述
本文说明同步表的更新过程与逻辑。
2. 说明
2.1 更新流程与状态
更新流程请参见下图：
1）手动触发或者调度触发，创建更新请求：
- 更新前检查通过，可以在更新记录列表中查看。
- 更新前检查失败，视为系统问题。
2）更新前检查通过：
- 资源充足且该表没有其他更新中请求时，将直接进入更新。
- 资源不充足或者该表有其他更新中请求时，进入等待更新状态，排到后进行更新。
- 等待更新状态与更新中状态可以手动中止。
2.2 更新策略
2.2.1 定时调度拉起更新
如果同步表正在更新中，被定时调度拉起，就会开始排队，只允许有一个最新的请求在排队，中间的会被跳过。
假设同步表A，每小时执行一次：
时刻 | 更新请求产生 | 更新状态 |
0点钟 | 接收更新请求A0（0点触发更新） | A0开始更新 |
1点钟 | 接收更新请求A1（1点触发更新） | A0还在正在更新中，A1在排队 |
2点钟 | 接收更新请求A2（2点触发更新） | A0还在正在更新中，A1被跳过，A2开始排队 |
3点钟 | 接收更新请求A3（3点触发更新） | A0还在正在更新中，A2被跳过，A3开始排队 |
2.2.2 手动更新
1）手动执行时可选择是否传播下游。详情请参见：同步表运维
2）如果同步表正在更新中，此时用户手动点击更新，就会开始排队，只允许有一个最新的请求在排队，中间的会被跳过。详细说明请参见本文 2.2.1 节内容。
3）源端为 SAAS 时，支持自定义数据同步起点。
2.2.3 增量读取量
增量读取时，从当前游标位置开始，到更新时发起同步的时间对应的数据最新位置结束。
也就是说，如果1点调度，进入排队，2点开始更新发起同步，4点结束，2点到4点新产生的数据不会被同步（这么做是为了避免来源端源源不断的生产数据导致同步表一直更新）。
如果是 SaaS 数据源，增量读取量由 DM 控制，逻辑一致。
400-111-0890
在线咨询