在 SQL Server 上配置始终在线的高可用性组

在本文中，我们将引导您逐步了解如何在 Windows Server 2019 上运行的 SQL Server 上安装和配置Always On可用性组，讨论故障转移方案以及其他一些相关主题。

Always On 可用性组在 Microsoft SQL Server 中提供高可用性。 Always On 出现在 MSSQL 2012 版本中。

SQL Server 中 Always On 可用性组的功能

SQL Server 可用性组可以用来做什么？

• MS SQL 高可用性和自动故障转移；

• 节点之间 SELECT 查询的负载平衡（辅助副本可能可读）；

• 从辅助副本进行备份；

• 数据冗余。每个副本都保留可用性组数据库的副本。

Always On 基于Windows Server 故障转移群集 (WSFC)。 WSFC 监视可用性组节点并提供自动故障转移。从 MS SQL Server 2017 开始，Always On 可以在没有 WSFC 的情况下使用，也可以在 Linux 主机中使用。构建基于Linux的集群时，可以使用Pacemaker代替WSFC。

Always On 在标准版本中可用，但有一些限制：

• 仅限 2 个副本（主副本和辅助副本）；

• 次要副本不能用于读取数据；

• 次要副本不能用于备份 MS SQL；

• 每个可用性组仅支持 1 个数据库。

企业版没有任何限制。
让我们考虑一下这些条款。

• Always On Availability Group是一组副本和数据库；

• 副本是可用性组中的 SQL Server 实例。副本可以是主要的或辅助的。每个副本可能包含一个或多个数据库。

Always On 基于 WSFC。每个可用性组节点必须是 Windows 故障转移群集的成员。每个 SQL Server 实例可以有多个可用性组。每个可用性组最多可以有 8 个辅助副本。

如果主副本发生故障，集群将投票选出新的主副本，并且 Always On 将使辅助副本之一成为主副本。由于用户在使用 Always On 时连接到侦听器（特殊的集群 IP 地址和相应的 DNS 名称），因此可以再次运行写入查询。侦听器还负责平衡辅助副本之间的 SELECT 查询。

为 Always On 可用性组配置 Windows 故障转移群集

首先，我们必须在Always On使用的所有节点上配置故障转移集群。

这是我的配置：

• 2 个运行 Windows Server 2019 的虚拟机

• 2 个 SQL Server 2019 企业版实例

• 节点主机名是 testnode1 和 testnode2。 SQL Server 实例名称为node1 和node2。

使用服务器管理器添加故障转移群集角色或通过 PowerShell 安装它：

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

安装是自动的，您无需配置任何内容。运行故障转移集群管理器管理单元 (

FailoverClusters.SnapInHelper.msc

）并创建一个新集群。

添加要加入集群的主机的名称。

然后向导提出进行一些测试。为此，请选择第一项。

指定集群名称、选择网络和集群 IP 地址。集群名称会自动出现在DNS中；您不需要手动创建 DNS 记录。在我的例子中，集群名称是ClusterAG。

取消选中将所有符合条件的存储添加到集群选项，因为我们可以稍后添加磁盘。

集群中只有两个节点，因此您必须配置集群仲裁。集群法定人数是决定性的一票。例如，如果集群节点之一变得不可用，集群必须检测哪些节点实际上在线并且可以互相看到。集群仲裁提供集群一致性（集群 -> 更多操作 -> 配置集群仲裁设置）。

选择仲裁见证选项。

然后选择见证类型：文件共享见证。

指定共享文件夹的 UNC 路径。自己创建目录。它必须位于故障转移群集外部的服务器上。

配置集群时，您可能会看到以下错误：

There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.

运行集群的用户帐户可能没有访问共享文件夹的 NTFS 权限。默认情况下，集群在本地用户帐户下运行。您可以向所有群集计算机授予对该文件夹的权限，或者更改群集服务的帐户并授予其相关权限。

基本的 Windows 故障转移群集配置已经结束。

在 MS SQL Server 上配置 Always On 可用性组

在典型的 SQL Server 实例安装后，您可以启用和配置 Always On 可用性组。在SQL Server 配置管理器的实例属性中启用它们。正如您在屏幕截图中看到的，SQL Server 已经检测到它属于 WSFC 集群。选中启用 Always On 可用性组并重新启动 MSSQL 实例服务。对第二个实例执行相同的操作。

提示。 在配置 Always On 之前，请确保 SQL Server 服务未在本地系统帐户下运行。建议使用组托管服务帐户或常用域帐户。否则，您将无法完成Always-On配置。

运行 SQL Server Management Studio，连接到主机，单击始终保持高可用性，然后运行新建可用性组向导。

在适用于 SQL Server 2017 和 SQL Server 2019 的 SQL Server Management Studio 18.x 中，出现了一些仅在 T-SQL 中可用的 Always On 设置，因此建议使用最新的 SSMS 版本。

为您的 Always On 可用性组指定名称，然后选择数据库级运行状况检测。使用此选项，Always On 将能够检测数据库何时不健康。

选择要添加到 Always On 可用性组的 SQL Server 数据库。

单击添加副本并连接第二个 SQL 服务器。因此您最多可以添加 8 台服务器。

• 初始角色是创建组时的副本角色。它可以是主要的或次要的；

• 自动故障转移 - 如果数据库不可用，Always On 会将主角色移动到另一个副本。检查此项；

• 可用性模式允许选择同步提交或异步提交。如果选择同步模式，则到达主副本的事务将通过同步模式发送到所有其他辅助副本。仅当其他副本将事务写入磁盘后，主副本才会完成事务。因此，如果主副本发生故障，就可以消除数据丢失。在异步模式下，主副本会立即写入更改，而无需等待其他副本的响应。

• 可读辅助是一个参数，允许对辅助副本运行 SELECT 查询。如果该值为 yes，则即使在没有连接的情况下客户端也将能够获得只读访问权限

  ApplicationIntent=readonly

  。

• 需要提交的同步辅助副本是完成事务所需的同步辅助副本的数量。根据副本数量来设置，我将其设置为1。

请勿在端点选项卡中编辑任何内容。

在备份首选项选项卡中，您可以选择备份的位置。保留此处的默认设置：首选次要。

指定可用性组侦听器的名称、端口和 IP 地址。

保持只读路由设置不变。

选择副本同步类型。我选中第一项（自动播种）。

然后您的设置必须得到验证。如果没有错误，请单击“完成”应用更改。

就我而言，所有测试均已成功，但在安装后的“结果”步骤中，向导显示创建可用性组侦听器时出错。集群事件日志中出现错误 EVENTID 1194：

Cluster network name resource failed to create its associated computer object in the domain.

这意味着集群没有足够的权限来创建侦听器。文档指出，向集群的对象授予创建计算机类型对象的权限就足够了。使用 AD 中的权限委派可以更轻松地完成此操作（或者快速但不安全的变体是将 CLUSTERAG$对象临时添加到域管理员组）。

在诊断可用性组中的始终在线和低 SQL 性能问题时，除了使用标准 SQL Server 诊断工具之外，还应该彻底研究 Windows 群集日志。

由于我创建了可用性组，但没有创建侦听器，因此我手动添加了它。打开可用性组的上下文菜单，然后单击添加侦听器。

指定侦听器的 IP 地址、端口和 DNS 名称。

确保侦听器已出现在 Always On 组的可用性组侦听器部分中。

至此，您已完成 Always On 可用性组的基本配置。

SQL Server Always On：可操作性检查和故障转移

我们来看看可用性组仪表板（Show Dashboard）。

没关系，该组已创建并正在运行。

让我们尝试手动将node2设为主实例。右键单击可用性组并选择故障转移。

请记下故障转移准备情况中的值。 无数据丢失表示不会丢失数据。

连接到节点2。

单击“完成”。

确保node2已成为可用性组中的主副本（Primary Instance）。

确保侦听器正常工作。在 SSMS 中指定侦听器 DNS 名称和端口，以逗号分隔：

ag1-listener-1,1445

对数据库运行简单的插入、选择和更新 SQL 查询。

然后检查主副本的自动故障转移。只需终止 TESTNODE2 上的 sqlservr.exe 进程即可。

检查剩余节点上的可用性组状态：TESTNODE1\NODE1。

集群已自动更改testnode1 自 testnode2 起 ode1 状态变为主节点 ode2 变得不可用。

检查侦听器状态，因为客户端将使用它进行连接。

就我而言，我成功连接到侦听器，但是在尝试访问数据库时，出现此错误：

Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.

由于需要同步辅助节点来提交选项而出现错误。由于我们在配置时将其值设置为 1，因此 Always On 不允许它连接到数据库，因为我们只剩下一个主副本。

将值设置为 0 并尝试再次运行查询。

Testnode1 保持 Primary 实例状态，而 testnode2 成为 secondary 实例。我们在testnode2断电时在testnode1上更改的数据在计算机打开后同步成功。

因此，我们确保一切正常运行，并且在发生严重故障时数据可供读/写。

您可以轻松配置 Always On 可用性组。如果您想构建基于 SQL Server 的故障转移解决方案，可用性组可以很好地管理它。