写在前面
业务连续性
每个人在部署 SQL Server 时都需执行一项常见任务，即确保所有任务关键型 SQL Server 实例以及其中的数据库在业务和最终用户需要时（无论是朝九晚五还是全天候）可用。 其目标是尽量减少或杜绝中断，保持业务正常运行。 此概念也称为业务连续性。
要想理解后面的所有内容，我们需要先理解什么是可用性组，什么是实例，什么是节点，什么是数据库，什么是副本。先将这些概念理清，才能理解后面其他的内容。
菜白我就在这几个概念当中挣扎了许久，后面也是经过高人指点才爬出了这个大坑。
基本概念
关于基本概念我这里推荐另一位博主写的两个博文，看了之后会对理解下面的内容大有裨益。
SQL Alwayson学习知识点（一）
SQL Alwayson学习知识点（二）
好我们看下面这张图，下图显示的是一个包含一个主要副本和四个次要副本的可用性组。 支持最多八个辅助副本，包括一个主副本和两个同步提交辅助副本。
可用性组：可用性组是下面图中第二层灰色的这部分，可用性组是一个逻辑上面的概念。
数据库副本：数据库是下图中最上面一层的白色方块，数据库是文件的集合，是依照某种数据模型组织起来并存放于二级存储器中的数据集合，也是一个逻辑概念。同时副本分为主要副本和次要副本[1]。
实例：数据库实例是程序，是位于用户和操作系统之间的一层数据管理软件，用户对数据库中的数据做任何的操作，包括数据定义、数据查询、数据维护、数据库运行控制等等都是在数据库实例下进行的，应用程序只有通过数据库实例才能和数据库打交道。实际上,正常的数据库读入内存的过程是,由实例中一组后台进程从磁盘上将数据文件读入到实例的内存中,然后经过在内存中对数据的操作再从实例的内存中经过一组后台进程写到数据库中。举个例子，如果把数据库比作一架飞机，实例就是飞机的发动机。那么，一台发动机可以驱动飞机，两台发动机也可以同时驱动一架飞机[2]。 在这里实例就是下图中黄色的部分。
节点：节点是下图中蓝色的部分，节点就是在集群当中提供算力的服务器或者虚拟机。
故障转移群集：故障转移集群就是图中最下面的白色框中的部分，是提供AlwaysOn的基础。
我们在了解了基本的一些概念之后我们看一下这篇文章的一个脉络，本文主要讲三种主要功能的简单原理，如果大家对图中其他功能感兴趣请大家移步微软官方文档。
1. 高可用性
Always On 可用性组
SQL Server 2012 中引入的 Always On 可用性组将数据库的每个事务发送到另一个实例，从而提供数据库级别的保护，该实例称为副本，其中包含处于特定状态的数据库副本。 可用性组可部署在 Standard 版本或 Enterprise 版本上。 参与可用性组的实例可以是独立实例，也可以是 Always On 故障转移群集实例（即下一节中介绍的 FCI）。由于在事务发生时将它发送到副本，建议在需要较低恢复点目标和恢复时间目标的情况下使用可用性组。副本之间的数据移动可以是同步的或异步的，Enterprise 版本允许同步多达三个副本（包括主要副本）。 可用性组具有一个数据库的完全读/写副本且位于主要副本上，而所有次要副本都不能直接从最终用户或应用程序接收事务。
因为可用性组只提供数据库级保护，而非实例级保护，所以需要为每个次要副本手动同步事务日志中未捕获的或数据库中未配置的任何内容。 必须手动同步的对象的一些示例为实例级登录、链接服务器和 SQL Server 代理作业。
可用性组还有一个名为侦听器的组件，该组件允许应用程序和最终用户在不知道哪个 SQL Server 实例承载着主要副本的情况下进行连接。 每个可用性组都有自己的侦听器。 虽然侦听器的实现在 Windows Server 与 Linux 上略有不同，但它提供的功能和使用方法是相同的。 下图显示了使用 Windows Server 故障转移群集 (WSFC) 的基于 Windows Server 的可用性组。 无论是在 Linux 还是 Windows Server 上，实现可用性必须具备 OS 层的基础群集。 该示例显示了以 WSFC 为基础群集的两个简单服务器、节点或配置。
就副本而言，Standard 版本和 Enterprise 版本具有不同的最大值。 Standard 版本中的可用性组（称为 Basic 可用性组）支持两个副本（一个主要副本和一个次要副本），且可用性组中只有一个数据库。 Enterprise 版本不仅允许在一个可用性组中配置多个数据库，而且拥有的副本总数可多达 9 个（1 个主要副本，8 个次要副本）。 Enterprise 版本还提供了其他可选权益，如可读次要副本和备份次要副本的能力等。
在可用性方面，可用性组可提供自动或手动故障转移。 如果配置了同步数据移动，并且主要副本和次要副本上的数据库处于同步状态，则会发生自动故障转移。 只要使用侦听器，且应用程序使用较高版本的 .NET（3.5 更新版本，或 4.0 及更高版本），则应能利用侦听器，在尽量减小甚至不影响最终用户的情况下进行故障转移。 可将使次要副本成为新的主要副本的故障转移配置为自动或手动，且测量的单位通常为秒。
下面的列表突出显示了 Windows Server 与 Linux 上的可用性组之间存在的一些差异：
- 由于基础群集在 Linux 和 Windows Server 上的工作方式不同，因此，在 Linux 上，可用性组的所有故障转移（手动或自动）都是通过群集完成的。 而在基于 Windows Server 的可用性组部署中，手动故障转移必须通过 SQL Server 完成。自动故障转移则由 Windows Server 和 Linux 上的基础群集处理。
- 在 SQL Server 2017 中，建议将 Linux 上的可用性组配置为至少三个副本。 这是因为基础群集的工作方式。 发布后，会提供两个副本配置的改进解决方案。
- 在 Linux 上，每个侦听器使用的公用名都在 DNS 中定义，而不是像 Windows Server 上那样在群集中定义。
AlwaysOn 故障转移群集实例
自 6.5 版以来，群集安装一直是 SQL Server 的一项功能。 FCI 称为实例，是一种行之有效的方法，可为整个 SQL Server 安装提供可用性。 这意味着如果基础服务器遇到问题，则实例内的所有内容（包括数据库、SQL Server 代理作业、链接服务器等）都将移到另一台服务器。 所有 FCI 都要求某种形式的共享存储，即使通过网络提供。 FCI 的资源只能在任何给定时间由一个节点运行和拥有。 下左图中，由群集的第一个节点拥有 FCI，这也意味着它拥有与之相关联的共享存储资源，这些资源用与存储相连的实线表示。故障转移后，所有权发生更改，如右图所示。
FCI 未出现数据丢失，但因为有一个数据副本，所以基础共享存储是单一故障点。 FCI 通常与其他可用性方法（如可用性组或日志传送）结合使用，具有数据库的冗余副本。 部署的其他方法应使用与 FCI 物理上分离的存储。 FCI 故障转移到另一个节点时，它会在一个节点上停止，并在另一个节点上启动，这类似于关闭服务器然后再打开。 FCI 遍历常规恢复过程，这意味着将回滚需要前滚的任何事务以及任何不完整的事务。 所以，数据库在从数据点到故障或手动故障转移的时间这一期间始终如一，没有数据丢失。 数据库仅在恢复完成后才可用，因此恢复时间取决于诸多因素，且通常比可用性组的故障转移时间更长。 但不利的一面是，对可用性组进行故障转移时，可能需要执行额外的任务才能使数据库可用，例如启用 SQL Server 代理作业。
如同可用性组一样，FCI 提取承载它的基础群集节点。 FCI 始终保留相同的名称。 应用程序和最终用户绝不会连接到节点；使用分配给 FCI 的唯一名称。 FCI 可作为一个承载主要副本或次要副本的实例加入可用性组。
下面的列表突出显示了 Windows Server 与 Linux 上的 FCI 之间存在的一些差异：
- 在 Windows Server 上，FCI 属于安装过程。 而 Linux 上的 FCI 则是在 SQL Server 安装完成后配置。
- Linux 仅支持每个主机安装一个 SQL Server，因此所有 FCI 都是默认实例。 Windows Server 支持每个 WSFC 具有最多 25 个 FCI。
- Linux 中 FCI 使用的公用名在 DNS 中定义，并且名称应与为 FCI 创建的资源相同。
日志传送
如果恢复点和恢复时间目标更灵活，或者数据库中的任务并不是极为关键，则日志传送是 SQL Server 中另一个可靠的可用性功能。 基于 SQL Server 的本机备份，日志传送过程自动生成事务日志备份，并将其复制到一个或多个称为热备用状态的实例，然后自动将事务日志备份应用于该备用实例。 日志传送使用 SQL Server 代理作业自动执行备份、复制和应用事务日志备份的过程。
可以说，在某种程度上使用日志传送的最大优点在于它会考虑人为错误。 事务日志的应用可能会延迟。 因此，如果有人在没有 WHERE 子句的情况下发出类似 UPDATE 的内容，则备用可能尚未更改，如此便可在修复主系统时切换到该备用实例。 虽然日志传送易于配置，但始终需要手动从主系统切换到热备用状态的实例（称为角色更改）。 角色更改通过 Transact-SQL 启动，并且像可用性组一样，必须手动同步事务日志中未捕获的所有对象。 还需配置每个数据库的日志传送，而单个可用性组可包含多个数据库。 与可用性组或 FCI 不同，日志传送不提取角色更改。 应用程序必须能够处理这种情况。 可以使用 DNS 别名 (CNAME) 等技术，但存在利弊，例如切换后 DNS 刷新需要一定的时间。
2. 灾难恢复
主要可用性位置遭遇地震或洪水等灾难事件时，企业必须做好准备，在其他地方将系统联机。 本部分介绍 SQL Server 可用性功能如何帮助实现业务连续性。
AlwaysOn 可用性组
可用性组的优点之一是可使用单个功能配置高可用性和灾难恢复。 由于不需要确保共享存储也具有高可用性，可以更轻松地实现在一个数据中心内具有用于高可用性的本地副本，在其他数据中心内具有用于灾难恢复的远程备份，且每个备份都有单独的存储。 确保冗余的代价是具有额外的数据库副本。 下面的示例为跨越多个数据中心的可用性组。 一个主要副本负责确保所有次要副本保持同步。
可用性组（群集类型为“无”的可用性组除外）要求所有副本都属于同一基础群集（无论是 WSFC 还是 Pacemaker）。 这意味着在上图中，WSFC 延伸到两个不同的数据中心，增加了复杂性。 无论使用什么平台（Windows Server 或 Linux）。 跨距离延伸群集会增加复杂性。 SQL Server 2016 中引入了分布式可用性组，它允许可用性组跨越在不同的群集上配置的可用性组。 这降低了节点必须全部位于同一个群集中这一要求，使配置灾难恢复更加容易。 有关分布式可用性组的详细信息，请参阅分布式可用性组。
AlwaysOn 故障转移群集实例
FCI 可用于灾难恢复。 与一般可用性组一样，基础群集机制也必须扩展到所有位置，这会增加复杂性。 FCI 还有一个注意事项：共享存储。 必须在主站点和辅助站点中使用相同的磁盘，因此需要借助外部方法，例如存储供应商在硬件层提供的功能或使用 Windows Server 中的存储副本，确保 FCI 使用的磁盘存在于其他地方。
日志传送
日志传送是为 SQL Server 数据库提供灾难恢复最古老的方法之一。 日志传送通常与可用性组和 FCI 结合使用，在其他选项可能由于环境、管理技能或预算而可能不太适用的情况下，提供经济高效且更简单的灾难恢复。 与日志传送的高可用性情况类似，许多环境会延迟加载事务日志，以便解决人为错误。
3. 迁移和升级
部署新实例或升级旧实例时，业务不容许出现长时间的中断。 本部分介绍如何使用 SQL Server 的可用性功能，最大限度地减少执行计划内体系结构更改、服务器交换、平台更改（例如 Windows Server 和 Linux 之间）时的停机时间或修补过程中的停机时间。
AlwaysOn 可用性组
包含一个或多个可用性组的现有实例可就地升级至 SQL Server 2017。 虽然这要求一定的停机时间，但可通过适量计划，将此时间减至最少。
如果目标是迁移到新服务器，而不更改配置（包括操作系统或 SQL Server 版本），那么可将这些服务器作为节点添加到现有基础群集，并添加到可用性组。 副本处于正确状态后，可以在新服务器启动手动故障转移，之后可将旧服务器从可用性组中删除并最终停止使用。
分布式 AG 也是另一种迁移到新配置或升级 SQL Server 的方法。 因为分布式 AG 在不同体系结构上支持不同的基础 AG，例如，可以从在 Windows Server 2012 R2 上运行的 SQL Server 2016 更改为在 Windows Sever 2016 上运行的 SQL Server 2017。
最后，群集类型为“无”的可用性组也可用于迁移或升级。 在典型的可用性组配置中，不能混合搭配群集类型，因此所有副本都需是“无”类型。 分布式可用性组可用于跨越配置了不同群集类型的可用性组。 不同的 OS 平台上也支持这种方法。
用于迁移和升级的可用性组的所有变体都允许超时完成工作中最耗时的部分 - 数据同步。 开始切换到新配置时，相对于长时间的停机，直接转换是短暂的中断，在此期间需完成包括数据同步在内的所有工作。
可用性组在正在完成修补时手动将主要副本故障转移到次要副本，从而最大限度地缩短基础 OS 修补期间的停机时间。 从操作系统的角度来看，在 Windows Server 上执行此操作更为常见，因为该基础 OS 的维护可能经常（但非始终）需要重启。 修补 Linux 有时也需要重启，但并不频繁。
修补参与可用性组的 SQL Server 实例也可以尽量减少停机时间，具体取决于可用性组体系结构的复杂程度。 若要修补参与可用性组的服务器，需先修补次要副本。 正确数量的副本修补完成后，将主要副本手动故障转移到另一个节点，进行升级。 此时还可升级任何剩余的次要副本。
AlwaysOn 故障转移群集实例
FCI 自身无法为传统的迁移或升级提供帮助；必须为 FCI 中的数据库以及参与其中的所有其他对象配置可用性组或日志传送。 然而，需要修补基础 Windows Server 时，Windows Server 中的 FCI 仍然是常用选项。 可启动手动故障转移，这意味着会出现短暂的中断，而不是使实例在整个 Windows Server 修补期间完全不可用。 FCI 可就地升级到 SQL Server 2017。 有关详细信息，请参阅升级 SQL Server 故障转移群集实例。
日志传送
日志传送仍然是迁移和升级数据库的常用选项。 与可用性组相似，但在这种情况下使用事务日志作为同步方法，可在服务器切换之前启动数据传播。 切换时，一旦所有流量在来源处停止，则记录最终事务日志，并将其复制、应用到新配置。 此时，数据库即可联机工作。 通常，日志传送对速度较慢的网络的包容性更强，虽然相较于使用可用性组或分布式可用性组执行的切换而言，这种切换可能耗时稍长，但通常也以分钟为单位，而不是以小时、天或周为单位。
与可用性组相似，日志传送可提供一种在修补时切换到其他服务器的方法。