SQL Server CDC能否在Always On备库读取？原理与实践

在 SQL Server 生产环境中，核心业务系统常年运行，进行数据同步时最让 DBA 担忧的是什么？一是避免影响主库性能，二是严格管控权限安全，三是确保已部署的 Always On 高可用架构充分发挥价值。这三大痛点几乎是每位数据库管理员首先考虑的问题。

CDC 的增量数据流转路径为：事务日志 → 捕获进程 → 变更表。同步任务在增量阶段仅需从 CDC 变更表中拉取数据。若已启用 Always On，完全可以将同步读取的负担转移到可读副本，主库专注于业务写入和 CDC 捕获；同步账户只需分配读取权限，从而将对核心库的性能影响降至最低。

SQL Server CDC 增量读取原理

关键要点：SQL Server CDC 增量读取的入口并非业务表本身，而是启用 CDC 后创建的 capture instance 及其对应的 CDC 变更表。

每个启用 CDC 的业务表都会关联一张 CDC 变更表，命名格式通常为 cdc._CT。当业务表发生 INSERT、UPDATE、DELETE 操作时，变更首先写入 SQL Server 事务日志，随后由 SQL Server Agent 的 CDC capture job 捕获，并写入相应的 CDC 变更表。

同步任务在消费增量数据时，主要访问 cdc 架构下的以下对象：cdc._CT 存储业务表的 DML 变更，是最核心的数据来源；cdc.change_tables 记录 capture instance、源表、起始 LSN 等信息，用于识别 CDC 表和可读范围；cdc.captured_columns、cdc.index_columns、cdc.ddl_history 等元数据则用于识别捕获列、索引列及 DDL 历史。

其中，_CT 表中的每条记录除业务字段外，还包含以下几类关键 CDC 字段：

• __$start_lsn：变更所属事务的提交 LSN，是增量进度推进的主要依据。
• __$seqval：同一 LSN 下的操作序列号，用于区分多条变更的执行顺序。
• __$operation：操作类型，1 代表删除，2 代表插入，3 代表更新前镜像，4 代表更新后镜像。
• __$update_mask：标识 UPDATE 操作涉及的列。

因此，SQL Server CDC 增量读取的核心逻辑十分清晰：按照 __$start_lsn、__$seqval、__$operation 等字段的顺序，逐条处理 _CT 表中的变更记录，然后将 INSERT、DELETE、UPDATE 的前后镜像转换为下游系统可处理的变更事件。

Always On 备库 CDC 原理

在 Always On 环境中，CDC 捕获仍然由主副本负责。业务 DML 写入事务日志后，SQL Server Agent 的 capture job 从日志中捕获变更，并写入主副本的 CDC 变更表；cleanup job 则根据配置的保留策略定期清理历史变更。

这些 CDC 变更表和元数据通过 Always On 日志同步和 Redo 过程在可读副本上保持可见。CloudCanal 连接到可读副本后，可直接读取已同步过来的 cdc._CT、cdc.change_tables 等对象，实现增量数据消费。

因此，在 Always On 场景下，优化的核心并非改变 CDC 的捕获方式，而是将同步任务对 CDC 表的持续查询从主副本转移到可读副本。主副本继续处理业务写入和 CDC 捕获，可读副本专门为同步链路提供 CDC 读取——各司其职，分工明确。

静态 CDC 与最小权限运行

SQL Server CDC 初始化需要较高权限：数据库级 CDC 要求 sysadmin 服务器角色，表级 CDC 和 capture instance 创建则需 db_owner 角色。这些操作通常由 DBA 在主库端一次性完成。

所谓“静态 CDC”，是指 CDC 相关对象由 DBA 预先创建完毕，后续同步任务在运行阶段不再动态创建 capture instance，仅消费已准备好的 CDC 表和元数据。

在该模式下，DBA 可以提前按照固定命名格式（db_schema_table_cc_static）为订阅表创建 CDC capture instance。后续同步账户只需对业务 schema 和 cdc schema 拥有 SELECT 权限，即可持续消费 CDC 数据，无需任何写入或管理类权限。

这种权限模型特别适用于核心数据库。同步账户无需长期持有 sysadmin 或 db_owner 权限，日常运行阶段仅保留读取权限。对于权限审计严格的 SQL Server 生产库而言，这往往是方案能否成功落地的关键因素。

表级多位点推进

在 SQL Server CDC 中，每张表的 _CT 捕获表相互独立，不同表的变更进度天然存在差异。若仅维护一个全局 LSN，会导致同步任务重复消费相同数据。

多位点机制的核心在于按表独立维护进度。每张表的位点主要记录当前读取的 LSN 和 __$seqval，读取 CDC 变更表时再结合 __$operation 识别操作类型：

• LSN：日志序列号，用于定位事务边界
• __$seqval：同一 LSN 内多条变更的序列值，用于区分同一事务内的操作顺序
• __$operation：操作类型（1=删除, 2=插入, 3=更新前, 4=更新后）

在多表订阅、任务暂停恢复、CDC 表积压等场景中，多位点机制更便于问题定位：哪张表读取到哪个位置、哪张表出现延迟，一目了然。

总结

在 SQL Server Always On 场景下，CDC 捕获仍由主副本执行，增量数据同步通过连接可读副本来读取 CDC 表。

这样做的好处显而易见：既能复用已有的高可用架构，降低同步读取对主库的影响，又能让运行账户保持最小权限。对于主库负载敏感、权限要求严格的核心 SQL Server 数据库而言，这是一种更适合长期稳定运行的 CDC 同步方案。