SQL Server 高可用性解决方案：2026 年 DBA 指南

实例级保护与数据库级保护：实例级保护（例如故障转移集群实例）可保护整个实例，包括所有数据库和服务器对象；而数据库级保护（例如 Always On 可用性组）可保护特定数据库。
同步数据移动与异步数据移动：同步数据移动可确保零数据丢失，但可能会引入延迟；而异步移动可优化性能，但可能会造成数据丢失。
自动故障转移与手动故障转移：自动故障转移无需人工干预即可最大限度地减少停机时间，而手动故障转移提供更大的控制权，但需要管理员操作。

2.2 常见的HA解决方案

SQL Server 提供八种主要高可用性解决方案，每种方案都针对特定场景：

Always On 可用性组
包含可用性组
分布式可用性组
故障转移集群实例
SQL Server 复制
原木运输
数据库镜像
托管实例链接

3. Always On 可用性组

Always On 可用性组代表 SQL Server的顶级数据库级高可用性和灾难恢复解决方案，于 SQL Server 2012 年。它使数据库组能够作为一个整体一起发生故障转移，同时提供可读的辅助副本以进行查询卸载。

主要功能

最多支持 9 个副本（1 个主副本 + 8 个从副本）
同步提交模式下最多支持 5 个副本（1 个主副本 + 4 个从副本）
同步模式下自动故障转移，数据零丢失
用于查询卸载的可读辅助副本
将备份卸载到辅助副本
用于自动连接路由的可用性组监听器
用于负载均衡读取查询的只读路由
多个数据库作为一个整体同时发生故障转移。

实施步骤

配置 Windows Server 故障转移群集 (WSFC) 或 Linux Pacemaker 群集
在所有设备上启用 Always On 可用性组功能 SQL Server 实例
确保数据库使用完整恢复模式并拥有完整备份。
在每个副本上创建数据库镜像端点
创建可用性组并添加数据库。
配置主副本和辅助副本所需的模式
创建并配置可用性组侦听器
如果使用可读辅助设备，请配置只读路由。
测试故障转移程序并验证应用程序连接性

最适合

需要最大限度正常运行时间的关键任务数据库
需要本地高可用性和地理灾难恢复的组织
需要读取缩放功能的环境
受益于卸载报表查询的应用程序
需要零数据丢失保护的数据库
需要协调故障转移的多数据库应用程序

优点

同步提交模式下零数据丢失
自动故障转移可最大限度地减少停机时间（通常为几秒）。
可读性强的辅助存储器可减轻主存储器的负载
无需共享存储
同时支持 Windows 和 Linux 平台
灾后恢复的地理分布
备份操作可以卸载到辅助节点。
故障转移后，应用程序连接字符串保持不变。

缺点

要使用全部功能，需要企业版。
标准版仅限 Basic AG（1 个数据库，1 个辅助数据库，无可读辅助数据库）
复杂配置和管理
需要集群基础设施（WSFC 或 Pacemaker）
实例级对象（登录名、作业）需要手动同步
同步模式可能会引入事务延迟。
许可cost适用于多个服务器

案例

4. 包含可用性组

包含可用性组，于 SQL Server 2022 年，通过自动跨副本同步实例级对象，扩展了传统的 Always On 可用性组，从而无需手动复制登录名、作业和其他服务器级对象。

主要功能

自动同步实例级对象（登录名、用户、角色）
SQL Server 代理作业已复制到所有副本
数据库权限自动同步
包含所有始终在线的农业生产功能
简化故障转移，实现完整的环境复制
同时支持 Windows 和 Linux 平台

实施步骤

确保 SQL Server 2022 年或之后所有实例
配置 WSFC 或 Pacemaker 集群基础架构
在所有实例上启用“始终开启”功能
创建包含可用性组（带 CONTAINED 选项）
将数据库添加到包含的 AG 中。
在 AG 环境中创建登录名和作业
配置监听器并测试故障转移

最适合

希望简化农业管理的组织
频繁进行故障转移测试或操作的环境
需要大量实例级对象的应用程序
全新发布 SQL Server 2022 年及以后的部署
寻求降低 p 的团队ost-故障转移配置

优点

无需手动同步登录信息和作业
更快、更可靠的故障转移
减少管理开销
应用程序在故障转移后立即恢复运行。
简化的灾难恢复程序
包括所有传统农业福利

缺点

要求 SQL Server 2022或更高版本
要使用全部功能，需要企业版。
无法将现有的传统AG转换为封闭式AG
所有副本必须支持包含的 AG 功能
与传统AG相比，复杂性更高

案例

微软官方文档：包含的可用性组

5. 分布式可用性组

分布式可用性组（Distributed Availability Groups）于 SQL Server 2016 年，启用“可用性组的可用性组”架构，将两个独立的可用性组连接起来，跨越不同的集群，以实现高级灾难恢复和迁移场景。

主要功能

连接两个独立的可用性组
每个AG都维护着自己独立的集群。
跨平台支持（Windows 到 Linux）
跨集群复制，无需共享集群成员资格
一个AG作为主要AG，另一个作为次要AG。
支持同步和异步模式
跨区域或跨大陆的地理分布

实施步骤

创建并配置第一个可用性组（主DAG）
创建并配置第二个可用性组（辅助DAG）
创建连接两个 AG 的分布式 AG
配置 AG 之间的数据同步
在每个 AG 上设置监听器以实现应用程序连接
配置故障转移策略和测试流程
验证跨集群通信和复制

最适合

跨独立数据中心的多区域灾难恢复
从 Windows 到 Linux 或反之亦然的跨平台迁移
混合云场景，将本地环境连接到 Azure
主要版本升级需要延长迁移窗口期
拥有多个独立故障转移集群的组织
需要跨洲复制的全球企业

优点

解耦站点间的集群依赖关系
实现真正的地理分布
支持跨平台场景
每个AG都可以独立发生故障转移。
非常适合复杂的迁移项目
无需共享集群基础设施
可以跨越不同的Windows域或Linux发行版

缺点

需要企业版
配置和管理的高度复杂性
需要对集群和农业技术有深入的了解。
比标准AG更难排除故障
跨区域场景的额外延迟
需要精心规划故障转移程序。

案例

微软官方文档：分布式可用性组

6.故障转移集群实例（FCI）

故障转移群集实例利用共享存储和 Windows Server 故障转移群集提供实例级高可用性，从而实现整个系统的自动故障转移。 SQL Server 实例包括所有数据库和服务器级对象。

主要功能

实例级保护（所有数据库同时故障转移）
采用共享存储的主动-被动配置
用于透明故障转移的虚拟网络名称 (VNN)
当活动节点发生故障时，自动进行故障转移
零数据丢失（数据单份副本）
服务器级对象包括（登录名、作业、链接服务器）
支持全部 SQL Server 恢复模型

实施步骤

配置 Windows Server 故障转移群集 (WSFC)
设置共享存储（SAN、SMB、存储空间直连）
配置集群仲裁设置
安装 SQL Server 作为第一个节点上的故障转移集群实例
向 FCI 添加其他节点
配置虚拟网络名称和 IP 地址
测试集群节点间的故障转移
配置客户端应用程序以使用 VNN

最适合

拥有现有共享存储基础架构的组织
需要实例级保护的环境
单个数据中心内的本地高可用性
需要所有数据库同时进行故障转移的应用程序
需要保护服务器级对象的场景
仅限 Windows 环境（FCI 不支持 Linux）

优点

完整的实例级保护
保证零数据丢失
自动故障转移能力
无需同步登录信息或作业
数据单副本减少存储空间osts
支持所有恢复模式
故障转移后应用程序连接字符串保持不变

缺点

需要昂贵的共享存储基础设施
共享存储是单点故障
无读取扩展能力（只有一个活动节点）
由于仓储限制，地理分布范围有限。
标准版仅限 2 个节点
仅限 Windows 系统（不支持 Linux 系统）
与 AG 相比，故障转移时间更长（通常为几分钟）。
复杂的存储配置和管理

案例

7. SQL Server 复制

SQL Server 复制是一种数据分发技术，它将数据复制并分发到多个服务器，支持从简单的单向分发到复杂的多主配置的各种拓扑结构，但主要用于报告，而不是纯粹的高可用性解决方案。

主要功能

四种复制类型：快照复制、事务复制、合并复制、点对点复制
细粒度数据选择（特定表、列、行）
支持来自同一出版商的多个订阅者
提供双向和多主拓扑结构
灵活的日程安排和同步选项
合并复制的冲突解决
使用 WHERE 谓词的过滤功能

实施步骤

配置分发服务器（可以与发布服务器分开，也可以与发布服务器相同）
在 Publisher 数据库中创建出版物
根据需求选择复制类型
选择要复制的文章（表、视图、存储过程）。
如有需要，请配置筛选和数据转换功能。
设置订阅者数据库
创建订阅（推送或拉取）
使用快照初始化订阅
监控复制代理和延迟

最适合

将数据分发到多个报表服务器
具有报告工作负载的读取规模场景
将部分数据分发到远程站点
来自多个来源的数据整合
偶尔会遇到连接场景（合并复制）
在灾后恢复战略中发挥辅助作用

优点

对复制数据进行精细控制
支持多个订阅者
灵活的拓扑结构选项
可以复制特定的表或列
过滤可以减少网络流量
支持异构复制（SQL Server 至 Oracle)
适用于标准版

缺点

无自动故障转移功能
复杂配置和管理
复制冲突的可能性（合并和点对点）
数据同步延迟
架构变更需要精心协调
并非设计为主要HA解决方案
故障排除可能充满挑战
点对点通信需要企业版

案例

8. 原木运输

日志传送通过自动化的事务日志备份、复制和恢复流程，提供热备灾难恢复和高可用性解决方案，简单易用且可靠。ost-维护同步辅助数据库的有效方法。

主要功能

通过 SQL Agent 实现自动备份、复制和还原作业
支持多个辅助服务器
可配置的备份和恢复间隔
待机模式允许对辅助驱动器进行只读访问。
延迟日志恢复以保护错误恢复
用于集中监控的监控服务器
事务日志压缩支持

实施步骤

确保主数据库使用完整恢复模式
创建主数据库的完整备份
使用 NORECOVERY 选项在辅助服务器上恢复备份
在主数据库上配置日志传送
指定所有服务器均可访问的共享备份文件夹
在主服务器上配置备份作业计划
在辅助服务器上配置复制和还原作业
（可选）配置监控服务器
测试故障转移程序

最适合

Cost有效的灾难恢复解决方案
拥有标准版许可的组织
能够容忍数分钟数据丢失的方案
能够适应手动故障转移的环境
延迟恢复以满足错误保护需求
使用备用模式报告工作负载
简单的灾难恢复需求，无需复杂的基础设施

优点

配置和操作简单
低 cost （标准版支持）
支持多个辅助服务器
可配置的延迟可防止逻辑错误
待机模式下的只读报告
能够容忍较高的网络延迟
对主服务器的影响极小
成熟可靠的技术

缺点

无自动故障转移功能
必须为每个数据库单独配置
同步延迟（分钟到小时）
根据备份间隔可能出现数据丢失
手动故障转移会增加恢复时间目标 (RTO)。
要求 SQL Server 代理程序在所有服务器上运行
日志恢复期间无法访问辅助数据库
应用程序在故障转移后需要更改连接字符串。

案例

9. 数据库镜像

数据库镜像是一种已弃用的数据库级高可用性解决方案，自那时起未获得任何增强。 SQL Server 2012 年版本虽然仍然可用，但微软强烈建议所有新部署都迁移到 Always On 可用性组。

主要功能

主服务器和镜像服务器架构
用于自动故障转移的可选见证服务器
两种运行模式：高安全性和高性能
支持同步和异步操作
自动页面修复功能
数据库级保护
支持数据传输加密

实施步骤

确保数据库使用完整恢复模式
创建完整备份并将其还原到镜像服务器，不启用恢复功能
在主体和镜像上创建镜像端点
配置用于身份验证的证书
在服务器之间建立镜像会话
可选择配置见证服务器以实现自动故障转移。
设置运行模式（高安全模式或高性能模式）
测试故障转移程序

最适合

已在使用数据库镜像的遗留系统
在迁移完成之前，将保留现有配置。
不建议使用其他方案（该功能已弃用）

优点

在高安全模式下，快速自动故障转移并有见证人
高安全模式下零数据丢失
来自合作伙伴的自动页面修复
比单个数据库的可用性组更简单
支持传输加密
滚动升级，最大限度减少停机时间

缺点

已弃用 SQL Server 2012（可能已删除）
每个数据库的配置和故障转移
无可读镜面（无读取刻度功能）
每个数据库独立发生故障转移
故障转移后需要更新连接字符串
仅限两台服务器（主服务器和镜像服务器）
没有改进或新增功能
微软建议迁移到 Always On 可用性组。

案例

数据库镜像（SQL Server)

10. 托管实例链接

托管实例链接在两者之间创建混合连接 SQL Server 以及使用分布式可用性组技术的 Azure SQL 托管实例，可实现近乎实时的数据复制，适用于灾难恢复、迁移和云集成场景。

主要功能

利用分布式 AG 技术实现近实时复制
单向复制（SQL Server 2016-2019 年（至 Azure）
双向复制带故障恢复（SQL Server 2022 +）
每个链接对应一个数据库（支持多个链接）
Azure SQL 托管实例上的可读副本
免许可被动式灾难恢复副本选项
在线迁移，停机时间最短

实施步骤

Prepare SQL Server 环境（VPN 或 ExpressRoute 到 Azure）
配置 Azure SQL 托管实例
启用“始终开启 AG”功能 SQL Server
创建数据库镜像端点
交换证书 SQL Server 和 MI
使用 SSMS 或脚本创建托管实例链接
验证复制和同步
如果用于读取缩放，请配置只读路由。
测试故障转移程序

最适合

采用基于云的备用方案的混合灾难恢复
在线迁移到 Azure SQL 托管实例
将分析和报告工作卸载到 Azure
采用混合云战略的组织
需要 Azure 服务集成的场景
Cost 利用免许可被动式灾难恢复进行优化

优点

Most 高效、停机时间最短的 Azure 迁移
真正实现向业务关键层级的在线迁移
双向故障转移 SQL Server 2022年
免许可被动式灾难恢复副本降低了 costs
与 Azure 服务集成，无需完全迁移
使用 Azure 副本的读取扩展功能
Azure 端的自动备份
地理分布到 Azure 区域

缺点

每个链接只能使用一个数据库
不能与 MI 上的故障转移组一起使用
系统数据库未复制
实例级对象需要手动同步
SQL Server 2016-2019年单向传输（无故障恢复）
Azure cost托管实例
网络连接要求（VPN/ExpressRoute）
功能限制（不支持文件表、文件流）

案例

11. 高可用性解决方案比较

11.1 功能对比表

特性	Always On AG	含有AG	分布式农业	FCI公司	复制	原木运输	镜像	小米链接
版本	Ent/Std	Ent/Std	耳鼻喉科	Ent/Std	Ent/Std	Ent/Std	Ent/Std	Ent/Std
防护等级	数据库	数据库实例	数据库	例	数据库/对象	数据库	数据库	数据库
数据同步	同步/异步	同步/异步	同步/异步	共享	异步	异步	同步/异步	异步
自动故障转移	是	是	是	是	没有	没有	是	没有
读取标尺	是	是	是	没有	是	有限	没有	是
RTO	秒	秒	秒	会议记录	用户手册	用户手册	秒	用户手册
RPO	零/分钟	零/分钟	零/分钟	零	最小	会议记录	零/分钟	最小
支持状态	活跃	活跃	活跃	活跃	活跃	活跃	已过时	活跃

11.2 选择HA解决方案

选择解决方案时，请考虑以下因素：

预算因素对解决方案选择有显著影响：企业版要求会影响许可协议。ost而基础设施需求则因 FCI 的昂贵共享存储和可用性组的通用服务器而异。
复杂程度差异很大：日志传送的实现最为简单，而分布式可用性组则需要丰富的专业知识。
恢复时间目标 (RTO) 要求决定了技术选择。秒级停机时间要求采用始终在线的可用性组或功能配置接口 (FCI)，并具备自动故障转移功能。分钟级的停机时间则允许采用手动故障转移解决方案，例如日志传送。
RPO 要求同样重要：零数据丢失要求同步解决方案，而分钟级容差则允许日志传送。
基础设施限制、读取规模需求、地理分布要求和云混合场景都会影响最佳解决方案的选择。

12. 最佳实践 SQL Server 高可用性

12.1 规划设计

通过对每个数据库进行细致的恢复时间目标 (RTO) 和恢复点目标 (RPO) 分析，评估业务需求。选择符合需求的合适解决方案，而不是默认采用现有方案。ost 提供完善的方案。采用分层方法，规划本地高可用性和异地灾难恢复。全面记录架构，包括网络图、故障转移流程和恢复手册。

12.2 实施指南

通过定期测试和模拟故障，定期测试故障转移程序，以验证其有效性。 SQL Server 高可用性解决方案和团队准备情况。持续监控运行状况和性能。 SQL Server的内置工具，例如 SQL Server 探查以及动态管理视图 (DMV)。配置针对同步延迟、故障转移事件和健康状况下降的全面警报。维护 SQL Server 备份策略尽管实施了高可用性 (HA) 系统，但备份仍然是防止逻辑损坏和意外删除的最后一道防线。务必使用累积更新、安全补丁和固件更新来保持系统最新状态。定期通过实际还原和应用程序测试来验证恢复流程，并了解如何处理以下情况：数据库卡在恢复模式.

12.3 监控维护

使用类似的工具 SQL Server 活动监视器, SQL Server 性能监视器以及用于健康监控和运行的动态管理视图 DBCC 检查数据库定期验证数据库完整性。利用 Always On 控制面板直观地评估可用性组的运行状况。密切监控同步延迟，特别是异步副本和日志传送的延迟。使用以下工具仔细跟踪故障转移事件： SQL Server 扩展活动并分析模式背后的原因。建立正常运行的性能基准，并监控偏差，以发现潜在问题。定期进行容量规划审查，确保基础设施能够支持不断增长的工作负载。

13。常问问题

问：高可用性和灾难恢复之间有什么区别？ SQL Server?

答：高可用性可最大限度地减少数据中心内局部故障造成的停机时间，通常采用自动故障转移，恢复时间目标 (RTO) 可在几秒或几分钟内实现。灾难恢复则可防范区域性灾难，通常采用手动故障转移，RTO 时间较长，但能覆盖影响整个设施的事件。

问：高可用性 (HA) 解决方案和读取扩展解决方案之间有什么区别？

答：高可用性解决方案确保数据库在故障期间仍可访问，侧重于正常运行时间和自动故障转移功能。读取扩展解决方案通过将只读工作负载分布到多个数据库副本上来提高查询性能，侧重于吞吐量和响应时间。虽然它们服务于不同的目的，但像 Always On 可用性组这样的同一项技术可以同时提供这两种优势：可读辅助副本提供读取扩展功能，同时还可用作故障转移。 tar获得高可用性。

问：哪个 SQL Server 高可用性解决方案最符合我的需求？

答：最佳解决方案取决于RTO和RPO。 tar获得预算、版本可用性、基础设施和专业知识。Always On Availability Groups 适合我ost 企业级场景，而日志传送则适用于 cost对环境要求敏感。请对照对比表评估相关要求。

问：Always On 可用性组是否需要企业版？

答：标准版支持基本可用性组，但存在诸多限制：每个组只能有一个数据库、一个辅助副本，且辅助副本不可读。要实现包括多个数据库、八个辅助副本和可读副本在内的完整功能，需要企业版。

问：我可以使用日志传送吗？ SQL Server 标准版？

答：是的，标准版完全支持日志传输，这使其成为一个极具吸引力的功能。ost- 为没有企业版许可证的组织提供有效的灾难恢复解决方案。

问：Always On可用性组和数据库镜像之间有什么区别？

答：数据库镜像功能已弃用，它在单个数据库级别运行，不提供可读的辅助访问权限。Always On 可用性组支持数据库组，最多支持八个辅助数据库，提供可读副本和增强的监控功能。微软建议迁移到 Always On。

问：如何选择故障转移集群实例和可用性组？

答：选择功能集配置项 (FCI) 可实现实例级保护并利用共享存储基础架构。选择可用性组 (Ag) 可实现数据库级保护、读取扩展能力和地理分布，但无需共享存储。企业通常会将两者结合使用，以获得更全面的保护。

问：我可以合并多个吗？ SQL Server 高可用性解决方案？

答：是的，组合使用多种解决方案很常见。FCI 可以作为可用性组的副本，提供实例级本地高可用性和数据库级异地灾难恢复。日志传送可以作为可用性组的补充，提供额外的远程保护。务必彻底测试组合配置。

问：同步复制和异步复制有什么区别？

答：同步复制在提交之前会等待辅助副本的确认，从而保证零数据丢失，但可能会引入延迟。异步复制则无需等待即可进行，优化了性能，但在故障转移期间可能会造成数据丢失。

问：如果我已经有了备份，还需要备份吗？ SQL Server 高可用性配置完成了吗？

答：绝对可以。高可用性可以防止硬件故障，但无法防止逻辑损坏、意外删除或恶意操作（这些操作会复制到所有副本）。备份对于时间点恢复和合规性要求仍然至关重要。

问：如果我已经有了备份，还需要备份吗？ SQL Server 高可用性配置完成了吗？

答：绝对可以。高可用性可以防止硬件故障，但无法防止数据库损坏、意外删除或恶意操作。备份对于时间点恢复和合规性要求仍然至关重要。如果数据库文件损坏，且备份不可用或也已损坏，则需要使用专门的备份方案。 SQL数据库修复软件可以帮助从损坏的 MDF、NDF 和备份文件中恢复数据。

问：什么是包含可用性组？它与普通可用性组有何不同？

A：包含可用性组，于 SQL Server 2022 版会自动同步实例级对象，例如登录信息、作业和元数据。常规可用性组仅同步数据库对象，实例对象需要手动复制。

问：我能否复制来自的数据？ SQL Server 到 Azure SQL 托管实例？

答：是的，托管实例链接提供混合复制功能。 SQL Server 和天蓝色。 SQL Server 2016-2019 年支持单向复制，而 SQL Server 2022+ 支持双向复制和故障恢复，适用于灾难恢复、迁移和混合场景。

问：会发生什么？ SQL Server 故障转移期间的代理任务？

答：使用传统可用性组时，必须在辅助副本上手动创建作业。包含可用性组（SQL Server 2022 年及之后版本）会自动同步作业。故障转移集群实例将作业包含在实例级保护范围内。

14. 结论

SQL Server 提供全面的高可用性解决方案，满足从部门数据库到关键任务型企业系统的各种需求。每种解决方案都具有独特的功能和优缺点，数据库管理员必须了解这些优缺点才能做出明智的决策。

Always On 可用性组是现代部署的旗舰技术，其中包含可用性组简化了管理，分布式可用性组则支持复杂的跨平台场景。故障转移集群实例继续满足实例级保护需求，而日志传送对于 c 仍然至关重要。ost敏感场景。托管实例链接开启了云混合部署的可能性，连接了本地环境。 SQL Server 使用 Azure。

根据具体业务需求匹配解决方案是成功的关键因素。没有一成不变的方案。企业必须仔细评估恢复时间目标 (RTO) 和恢复点目标 (RPO) 要求、预算限制、基础设施能力和管理经验。通常，最佳架构会结合多种解决方案，以实现全面保护。请考虑您的高可用性 (HA) 策略如何与更广泛的云采用计划相协调，并参考相关文章获取详细的实施指导，以确保您的成功。 SQL Server 基础设施能够提供您的业务所需的可靠性。

关于作者

袁盛是一位高级数据库管理员 (DBA)，拥有超过 10 年的 SQL Server 环境和企业数据库管理。他成功解决了金融服务、医疗保健和制造等行业的数百个数据库恢复场景。

袁专长于 SQL Server 数据库恢复、高可用性解决方案和性能优化。他拥有丰富的实践经验，包括管理多TB数据库、实施Always On可用性组以及为关键业务系统开发自动备份和恢复策略。

通过他的技术专长和实践方法，袁致力于创建全面的指南，帮助数据库管理员和 IT 专业人员解决复杂的 SQL Server 高效应对挑战。他始终掌握最新 SQL Server 版本和微软不断发展的数据库技术，定期测试恢复场景以确保他的建议反映现实世界的最佳实践。

有关于的问题 SQL Server 恢复或需要额外的数据库故障排除指导？袁欢迎反馈和建议用于改进这些技术资源。

SQL Server 高可用性解决方案：DBA 完整指南 [2026]

1. 介绍 SQL Server 高可用性

2. SQL Server 高可用性解决方案概述

2.1 HA解决方案的类别

2.2 常见的HA解决方案

3. Always On 可用性组

主要功能

实施步骤

最适合

优点

缺点

案例

4. 包含可用性组

主要功能

实施步骤

最适合

优点

缺点

案例

5. 分布式可用性组

主要功能

实施步骤

最适合

优点

缺点

案例

6.故障转移集群实例（FCI）

主要功能

实施步骤

最适合

优点

缺点

案例

7. SQL Server 复制

主要功能

实施步骤

最适合

优点

缺点

案例

8. 原木运输

主要功能

实施步骤

最适合

优点

缺点

案例

9. 数据库镜像

主要功能

实施步骤

最适合

优点

缺点

案例

10. 托管实例链接

主要功能

实施步骤

最适合

优点

缺点

案例

11. 高可用性解决方案比较

11.1 功能对比表

11.2 选择HA解决方案

12. 最佳实践 SQL Server 高可用性

12.1 规划设计

12.2 实施指南

12.3 监控维护

13。 常问问题

14. 结论

关于作者

13。常问问题