在 Debian 上实现 SQL Server 高可用的可行路径
一 支持性与总体建议
- 生产环境优先选择在受支持的 Linux 发行版（如 Ubuntu 20.04/22.04 LTS） 或 Windows Server 上部署 SQL Server，以获得完整的高可用特性、补丁与官方支持。
- Debian 并非微软官方支持平台；若在此环境运行，多为社区或非官方方式，存在维护与兼容性风险。若必须落地，可考虑在 Debian 上以容器方式运行受支持的 SQL Server 镜像，将高可用能力交由容器编排/集群层实现。
二 方案总览与选型
| 方案 |
适用场景 |
关键要点 |
在 Debian 上的可行性 |
| Always On 可用性组（AG） |
需要高可用 + 读写分离/只读副本 |
需 企业版、域无关可用性组（Linux 上）、至少 2 个副本、数据库需 FULL 恢复模型 且定期日志备份 |
技术上可在受支持的 Linux 上实现；在 Debian 上不推荐作为生产首选 |
| 故障转移群集实例（FCI） |
实例级高可用、共享存储 |
需共享块存储（如 iSCSI/FC/SAN）与集群管理；Linux 上依赖 Pacemaker/Corosync |
在 Debian 上搭建与维护复杂度高，且受限于共享存储与发行版支持 |
| 日志传送（Log Shipping） |
低成本温备/近实时 |
主库日志备份→复制到备库→连续还原；切换需手动，存在 RPO>0 |
在 Debian 上可行，作为兜底与演练方案 |
| 事务复制（Transactional Replication） |
特定库/表的高可用与分发 |
面向对象的复制，非整库；支持 读写分离 与 延迟可控 |
在 Debian 上可行，适合报表/查询分流 |
| 数据库镜像（已不推荐） |
旧版本兼容 |
仅数据库级、无系统库；高安全/高性能模式；微软已建议转向 AG |
不建议在新环境采用 |
| 第三方代理/负载均衡（如 Moebius） |
读写分离与连接级调度 |
通过中间层分发读写、支持故障切换 |
在 Debian 上可部署代理层，但需充分测试与评估厂商支持策略 |
| 上述技术特性与适用场景对比，综合自对 Always On、FCI、日志传送、复制、数据库镜像 等机制的原理与限制说明。 |
|
|
|
三 在 Debian 上的落地步骤范式（以日志传送为例）
- 前提准备
- 两台 Debian 主机安装并初始化 SQL Server，开放 1433/TCP 与用于日志传送的 自定义端口；创建用于复制的 共享目录/凭证。
- 主库数据库设置为 FULL 恢复模型，并建立 完整备份 作为日志链起点。
- 配置日志传送主库
- 在主库执行备份作业（示例）：
- BACKUP DATABASE [YourDB] TO DISK = N’/var/opt/mssql/backup/YourDB_full.bak’ WITH INIT;
- BACKUP LOG [YourDB] TO DISK = N’/var/opt/mssql/backup/YourDB_log.trn’ WITH INIT;
- 配置 msdb.dbo.sp_add_log_shipping_primary（主库）与 msdb.dbo.sp_add_log_shipping_secondary（备库）存储过程，设置：备份路径、复制作业、还原作业、保留策略与阈值告警。
- 配置日志传送备库
- 初始化备库：先还原一次 完整备份（WITH NORECOVERY），随后持续 RESTORE LOG … WITH NORECOVERY。
- 监控 LSBackup/LSCopy/LSRestore 作业状态，确保延迟与失败告警正常。
- 切换与回切
- 计划内切换：在主库停机维护前，完成日志备份→复制→还原到最新→在备库执行 RESTORE DATABASE [YourDB] WITH RECOVERY 并对外切换连接。
- 回切：反向执行日志传送链路并恢复主库。
- 适用性与注意
- 日志传送提供 数据库级 保护，RPO>0、切换需人工，适合作为 温备/近实时 与 演练 方案。
四 网络、存储与运维要点
- 网络与端口
- 开放 1433（客户端）、5022（端点通信，若使用镜像/AG）、以及日志传送作业使用的端口；确保 主机名解析 与 TLS/证书 一致性与正确性。
- 存储与文件系统
- 若采用 FCI，需准备 共享块存储（iSCSI/FC/SAN），并在集群层管理仲裁与隔离；确保 多路径 I/O 与 一致性组 配置正确。
- 安全与权限
- 使用 最小权限 的服务账户；为端点、备份、复制与代理配置 强密码/证书；限制管理端口访问。
- 监控与演练
- 监控 备份/复制/还原延迟、副本同步健康、日志增长 与 磁盘/CPU/内存；定期执行 故障转移演练 与 备份恢复演练，验证 RPO/RTO 指标。
- 维护与升级
- 采用 滚动升级 与 维护窗口；变更前完成 全量备份 与 配置快照；在 Debian 上尤其要重视 补丁与内核更新 对 SQL Server 与集群组件的影响。
五 更稳妥的替代部署
- 生产环境建议：
- 在 Ubuntu 20.04/22.04 LTS 上部署 SQL Server 企业版，启用 Always On 可用性组（至少 2 个副本，配置 自动故障转移 与 可读辅助副本），前端通过 HAProxy/Keepalived 提供 VIP/连接路由 与读写分离。
- 若需实例级保护且具备共享存储，采用 FCI + Pacemaker/Corosync 的受支持 Linux 集群方案。
- 若必须在 Debian 上运行：
- 优先选择 容器化（在受支持的 Linux 宿主机上运行官方 SQL Server 容器），将 高可用/调度 交给 Kubernetes/容器编排 与 外部负载均衡 实现，以降低平台限制带来的风险。