CentOS 上 SQL Server 复制的核心原理
在 CentOS 上运行的 SQL Server 采用与平台无关的“发布-分发-订阅”模型来在多个数据库实例间分发与同步数据。核心思路是由 发布服务器 Publisher 产生数据变更，分发服务器 Distributor 通过 分发数据库 可靠地存储与转发变更，订阅服务器 Subscriber 接收并应用这些变更。复制的三种基本类型为：快照复制（按时间点全量拷贝）、事务复制（基于事务日志的近实时增量）、合并复制（多端可更新并支持冲突解决）。该模型用于数据分发与同步，并非专用于灾难恢复场景。
核心组件与数据流
- 基本要素
- 发布服务器 Publisher：源数据所在，定义要发布的对象与数据。
- 分发服务器 Distributor：承载 分发数据库，保存元数据、历史与待分发命令，作为“存储-转发”中枢。
- 订阅服务器 Subscriber：接收并应用变更，可为只读或允许更新（取决于复制类型与选项）。
- 发布 Publication / 文章 Article：发布是对象的逻辑集合；文章是具体被复制的对象（如表、视图等）。
- 复制代理
- 快照代理 Snapshot Agent：生成初始快照（架构与数据），供首次同步使用。
- 日志读取器代理 Log Reader Agent：仅用于事务复制，持续读取发布库事务日志中标记为复制的事务并写入分发数据库。
- 分发代理 Distribution Agent：将初始快照与分发数据库中的增量命令应用到订阅库；支持推订阅（在分发端运行）与拉订阅（在订阅端运行）。
- 合并代理 Merge Agent：用于合并复制，负责初始快照与增量变更的双向同步与冲突处理。
- 队列读取器代理 Queue Reader Agent：当使用“排队更新”选项时，将订阅端更改回传到发布端。
- 典型数据流（事务复制）
- 在发布库提交事务并写入事务日志；2) 日志读取器 将已标记复制的事务送入 分发数据库；3) 分发代理 按设定频率/连续地将命令推送到订阅库并应用；4) 订阅库保持与发布库在事务边界上的一致性。
三种复制类型对比
| 复制类型 |
数据跟踪与传输 |
初始同步 |
典型场景 |
主要特点 |
| 快照复制 |
不跟踪增量，按时间点全量拷贝 |
快照文件 |
数据变动少、允许滞后、或短期大量变更后一次性同步 |
实现简单、网络与存储开销相对高 |
| 事务复制 |
读取事务日志，按事务增量传输 |
快照 + 增量日志 |
近实时分发、低延迟、服务器到服务器 |
订阅端通常只读；支持“立即/排队更新”与“对等复制”等扩展 |
| 合并复制 |
使用触发器与系统表跟踪多端变更 |
快照 + 增量合并 |
多站点/离线编辑、双向同步、需冲突解决 |
灵活自治，但设计与冲突处理更复杂 |
| 上述差异决定了在不同业务对延迟、自治性与冲突处理需求上的取舍。 |
|
|
|
|
部署与运行要点（CentOS 环境）
- 运行环境：在 Linux（如 CentOS） 上，SQL Server 复制组件以服务方式运行，依赖 SQL Server 代理 SQL Server Agent 调度与执行各代理；网络与权限配置与平台无关。
- 关键配置
- 正确设置 分发数据库 与 快照文件夹（建议使用可共享的 UNC 路径），并确保 SQL Server 代理服务 与复制代理所用账户具备相应权限。
- 订阅模式选择：需要低延迟与集中控制可用推订阅；订阅端自治与负载分离可用拉订阅。
- 高可用与灾备定位：复制用于数据分发与同步，并非完整的 HA/DR 方案；若以灾备为目标，通常优先考虑 日志传送、数据库镜像 或 Always On 可用性组 等机制。