处理 DDL 和方案演化

预期序号

当表定义更改并启用 DDL 捕获时，流可以在使用新定义的后续记录之前传送 DDL 记录，然后更新对象元数据和特定于表的 DML 方案。跨 WebSocket 消息的确切批处理和排序是实施详细信息；使用者必须在出现方案或元数据记录时对其进行处理。

• 通过其 id（不仅通过表名）缓存方案。

• 通过 qual_table 高速缓存对象元数据，并在新记录到达时将其替换。

• 不要假设在连接时收到的方案在连接的有效期内仍然有效。

• 如果 DML 记录所需的方案未知，且下游系统无法接受无模式数据，则暂停 DML 记录或向其发出死信。

• 在策略允许的地方自动应用兼容的更改；将不兼容的更改路由到受控的迁移工作流。

兼容和不兼容的更改

更改	典型的使用者操作
添加可为空的列	接受新字段并异步或动态更新下游方案。
添加非 Null 列	在应用记录之前确认默认/反向填充行为。
删除列	停止写入字段；根据保留策略保留历史下游数据。
重命名列	除非存在受监管的映射状态，否则视为删除加添加。
更改 JSON 基元类型或源精度	在继续之前验证转换、精度和下游兼容性。
更改键列	在使用新关键字下的记录之前，重新构建幂等性、合并和删除逻辑。

DDL 处理策略

• 在审计日志中记录 DDL pos、对象标识、语句和操作时间戳。

• 请勿直接对下游系统执行未经审核的源 DDL，除非明确批准并保护该行为。

• 使用足够大的 maxDDLTextSize 来支持组织的 DDL，并在检测到或怀疑截断时发出预警。

• 同一表在一段时间内需要多个方案版本。将方案标识符保留为已归档事件。

方案注册表集成

使用者可以将带内 JSON 方案记录发布到企业方案注册表。保留原始 id，将其与数据流和部署关联，以及版本更改，而不是覆盖历史方案定义。注册表是对运行时方案的补充；它不会替换检查点或源线索恢复。