sqlserver2019 alwayson集群搭建

一、准备工作

注：X盘为仲裁，仲裁可以是存储上分出来的硬盘，也可以是共享文件夹，在故障转移集群里设置

硬盘环境如下

二、故障转移集群搭建

域控制器的搭建就不再说了，之前的文章里搭建过了，安装故障转移集群前先把两台服务器加入域控，当然，alwayson集群可以实现无域搭建，这个以后再说

1、安装故障转移集群角色和功能，两台都要安装，这里我只在其中一台演示

选择故障转移集群功能

点击安装，等待安装完成，一般是不会出现意外的，安装完成之后开始配置

二，配置故障转移集群

点击故障转移集群管理器

先验证一下配置，做个体检

将两台主机名添加到集群里去，加域控作DNS之后直接填主机名就行，如果解析还没生效就填IP地址

运行所有测试

测试通过就行，警告无视，然后选择用经过验证的节点创建集群，图里我没勾选，但是懒得再截图了

创建集群，选择下一步

集群名称随意，但不要与域中已有的计算机名重复，域中有哪些计算机名可以在域控制器中查看

创建完成，验证一下配置

X盘已经成仲裁的样子了

目前没有任何角色

二、数据库安装

两台都要安装，安装步骤，安装路径都一样，我也只演示一遍

不需要说明的步骤我都跳过

选择自己需要的功能

实例根目录设置成H盘

实例名默认

把sqlserver代理和SQL server引擎设置为域用户，可以是域管理员，生产环境建议单独设置一个账户用来管理

输入域控的用户名和密码

选择域控管理员

点击确认，密码我设置的和域控密码一样

数据库引擎配置

点击安装

安装完成

三、配置alwayson集群

1、安装ssms管理器

直接点击安装，等待安装完成

2、开启alwayson功能，以下两台都要操作

右键windows图标，选择计算机管理

右键sqlserver服务，启用alwayson，然后点应用

再重启服务，就可以了

3、创建数据库，备份数据库，配置共享文件夹，一下在alwayson1运行

创建test测试库

在H盘新建backup文件夹用于数据库备份，并设置共享

设置权限为读取和写入

备份test测试库

将数据库被分到刚刚新建的backup文件夹

4、创建高可用性组，在alwayson1上配置就行

选择新建高可用性组向导，忽略，下一步

可用性组名称可以自己设置

关于数据库级别运行状况检测的说明

可用性组数据库级别运行状况检测选项是一个广泛推荐的有用选项，有助于保证数据库的高可用性。 应考虑对所有可用性组启用此选项。 如果应用程序依赖几个数据库实现高可用性，则可将这些数据库分在一个可用性组中并启用数据库运行状况选项。

例如，在数据库级别运行状况检测选项处于启用状态时，如果 SQL Server 不能写入其中一个数据库的事务日志文件，该数据库的状态会改为指示故障，可用性组会快速故障转移，然后应用程序可能重新连接，并在数据库再次联机后继续努力将中断次数降到最低。

选择test数据库

添加alwayson2为副本

可以看到数据库已经同步了

在主库上创建一个表测试一下

很好没问题

一些概念和注意事项

注意事项

请务必注意，“数据库级别运行状况检测”选项当前不会引起 SQL Server 监视磁盘运行时间，并且 SQL Server 不会直接监视数据库文件可用性。 如果磁盘驱动器故障或不可用，单独这一问题不一定会触发可用性组执行自动故障转移。

举例来说，当数据库处于没有活动事务且没有物理写入的空闲状态时，如果某些数据库文件不可访问，SQL Server 可能不会向文件执行任何读写 IO 的操作，可能也不会立刻更改该数据库的状态，因此不会触发故障转移。 随后，当出现数据库检查点或发生物理读写以完成查询时，SQL Server 可能此时才发现文件问题并通过更改数据库状态做出反应，然后，由于数据库运行状况更改，已启用数据库级别运行状况监测的可用性组将发生故障转移。

另一个例子是，当 SQL Server 数据库引擎需要读取数据页面以完成查询时，如果数据页面在缓冲池内存中缓存，则可能不需要通过物理访问进行磁盘读取即可完成查询请求。 因此，数据文件丢失或不可用可能不会立刻触发故障转移（即使已启用数据库运行状况选项），因为数据库状态不会立即更改。

数据库故障转移与灵活的故障转移策略相互独立

数据库级别运行状况检测可实现灵活的故障转移策略，用于针对故障转移策略配置 SQL Server 进程运行状况的阈值。 数据库级别运行状况检测使用 DB_FAILOVER 参数进行配置，而可用性组选项 FAILURE_CONDITION_LEVEL 单独用于配置 SQL Server 进程运行状况检测。 两个选项是独立的。

侦听器参数

可用性组侦听器使用以下内容：

唯一的 DNS 名称
这也称为虚拟网络名称 (VNN)。 适用 DNS 主机名的 Active Directory 命名规则。 有关详细信息，请参阅知识库文章： Active Directory 中计算机、域、站点和 OU 的命名约定 。

一个或多个虚拟 IP 地址 (VIP)
为可用性组可以故障转移到的一个或多个子网配置 VIP。

IP 地址配置
对于给定的可用性组侦听器，IP 地址可以使用动态主机配置协议 (DHCP)，或者一个或多个静态 IP 地址。 使用 DHCP 可能会导致故障转移期间的连接延迟，因此不建议在生产环境中使用。 跨多个子网扩展或使用混合网络配置的可用性组必须使用静态 IP 地址。

 侦听器端口

配置可用性组侦听程序时，必须通过 SSMS 指定一个端口。  您可以将默认端口配置为 1433，以便允许使用客户端连接字符串以达到简化目的。 这意味着，如果使用 1433，则无需在应用程序的连接字符串中包含端口号。 此外，由于每个可用性组侦听器都将具有一个独立的虚拟网络名称，因此，在单个 WSFC 上配置的每个可用性组侦听器都可以配置为引用相同的默认端口 1433。

如果对可用性组侦听程序 VNN 使用默认端口 1433，则仍需要确保群集节点上没有其他服务正在使用此端口；否则将导致端口冲突。

如果其中一个 SQL Server 实例已正在通过实例侦听器侦听 TCP 端口 1433，且在侦听端口 1433 的计算机上没有任何其他服务（包括其他 SQL Server 实例），则不会与可用性组侦听程序的端口导致冲突。   这是因为，可用性组侦听程序在相同过程中可以共享同一个 TCP 端口。  但是，不能将 SQL Server（并行）的多个实例配置为侦听同一端口，因为其中一个实例无法侦听连接。

还可指定非标准可用性组侦听程序端口。 但在连接到侦听器时，还需要在应用程序连接字符串中显式使用目标端口。  你还需要为此端口打开对防火墙的权限。

可使用名称和端口（端口 1433 除外）连接到侦听器。 端口可以是侦听器端口，也可以是配置为侦听的基础 SQL Server 端口。

Always On 可用性组是在 SQL Server 2012 (11.x) 中引入的高可用性和灾难恢复解决方案，它要求 Windows Server 故障转移群集 (WSFC)。 此外，尽管 Always On 可用性组 不依赖于 SQL Server 故障转移群集，但您可以使用故障转移群集实例 (FCI) 来为可用性组承载可用性副本。 因此，了解每种群集技术所扮演的角色以及设计您的 Always On 可用性组 环境所需的注意事项十分重要。

备注

有关 Always On 可用性组 概念的详细信息，请参阅 Always On 可用性组概述 (SQL Server)。

Windows Server 故障转移群集和可用性组

部署 Always On 可用性组 需要 Windows Server 故障转移群集 (WSFC)。 若要为 Always On 可用性组 启用，SQL Server 实例必须驻留在某一 WSFC 节点上，并且该 WSFC 和节点必须处于联机状态。 此外，给定可用性组的每个可用性副本都必须位于相同 WSFC 的不同节点上。 唯一的例外是在迁移到另一个 WSFC 时，此时一个可用性组可能会暂时跨两个群集。

Always On 可用性组 依赖 Windows Server 故障转移群集 (WSFC) 来监视和管理属于给定可用性组的可用性副本的当前角色，以及确定故障转移事件如何影响可用性副本。 为您创建的每个可用性组创建一个 WSFC 资源组。 WSFC 监视此资源组，以评估主要副本的运行状况。

针对 Always On 可用性组 的仲裁基于 WSFC 中的所有节点，而与给定群集节点是否托管任何可用性副本无关。 与数据库镜像相反，在 Always On 可用性组中没有见证服务器角色。

WSFC 的总体运行状况由群集中节点的仲裁投票决定。 如果 WSFC 因计划外灾难或由于持续的硬件或通信故障而脱机，则需要管理员手动干预。 Windows Server 或 WSFC 管理员将需要“强制仲裁”，然后在非容错配置中将仍有效的群集节点重新变为联机状态。

重要

Always On 可用性组 注册表项是 WSFC 的子项。 如果删除后重新创建了 WSFC，则必须在其原始 WSFC 上托管可用性副本的每个 Always On 可用性组 实例上都禁用然后重新启用 SQL Server 功能。

有关在 WSFC 节点上运行 SQL Server 的信息以及有关 WSFC 仲裁的信息，请参阅 Windows Server 故障转移群集 (WSFC) 与 SQL Server。

 SQL Server 故障转移群集实例 (FCI) 和可用性组

可以通过将 SQL Server FCI 与 WSFC 一起实现，在服务器-实例级别设置第二层故障转移。 可用性副本可由 SQL Server 的独立实例或 FCI 实例承载。 对于某一给定可用性组，一个 FCI 伙伴只能承载一个副本。 当某一可用性副本正在一个 FCI 上运行时，可用性组的可能所有者列表将只包含活动的 FCI 节点。

Always On 可用性组 不依赖于任何共享存储形式。 但是，如果使用 SQL Server 故障转移群集实例 (FCI) 来承载一个或多个可用性副本，每个 FCI 将需要标准 SQL Server 故障转移群集实例安装所要求的共享存储。

有关其它先决条件的详细信息，请参阅针对 Always On 可用性组的先决条件、限制和建议 (SQL Server) 的“使用 SQL Server 故障转移群集实例 (FCI) 承载可用性副本的先决条件和限制”部分。

比较故障转移群集实例和可用性组

无论 FCI 中的节点数是多少，整个 FCI 都只承载可用性组内的一个副本。 下表说明 FCI 中的节点和可用性组内的副本的概念区别。

*尽管可用性组中的同步次要副本始终在相应的 SQL Server 实例上运行，但 FCI 内的辅助节点实际未启动相应的 SQL Server 实例，因此不可读。 在 FCI 中，仅在 FCI 故障转移期间资源组所有权转移给辅助节点时，辅助节点才启动其 SQL Server 实例。 但是，在活动 FCI 节点上，当 FCI 承载的数据库属于可用性组时，如果本地可用性副本正在作为可读辅助副本运行，则数据库是可读的。

**可用性组的故障转移策略设置应用于所有副本，无论它位于独立实例还是 FCI 实例中。

备注

有关不同版本的 SQL Server 中 FCI 内的节点数和 Always On 可用性组的详细信息，请参阅 SQL Server 2012 各个版本支持的功能 (https://go.microsoft.com/fwlink/?linkid=232473)。

FCI 上承载可用性副本的注意事项

重要

如果计划在 SQL Server 故障转移群集实例 (FCI) 上承载可用性副本，请确保 Windows Server 2008 主机节点满足故障转移群集实例 (FCI) 的 AlwaysOn 先决条件和限制。 有关详细信息，请参阅针对 AlwaysOn 可用性组的先决条件、限制和建议 (SQL Server)。

SQL Server 故障转移群集实例 (FCI) 不支持通过可用性组来自动进行故障转移，因此只能为手动故障转移配置任何由 FCI 承载的可用性副本。

可能需要配置 WSFC 以包含并非在所有节点上可用的共享磁盘。 例如，考虑跨两个数据中心、包含三个节点的 WSFC。 其中两个节点在主数据中心托管 SQL Server 故障转移群集实例 (FCI)，并且有权访问相同的共享磁盘。 第三个节点在另一个数据中心中承载独立 SQL Server 实例，并且无权访问主数据中心的共享磁盘。 如果 FCI 托管主要副本，而独立实例托管次要副本，则此 WSFC 配置支持部署可用性组。

选择 FCI 承载给定可用性组的可用性副本时，请确保 FCI 故障转移不会导致单个 WSFC 节点尝试承载同一可用性组的两个可用性副本。

下面的示例方案说明此配置是如何导致问题的：

Marcel 配置具有两个节点（NODE01 和 NODE02）的 WSFC。 他在 SQL Server 和 fciInstance1上安装一个 NODE01 故障转移群集实例 NODE02 ，其中 NODE01 是 fciInstance1的当前所有者。
在 NODE02上，Marcel 安装了另一个 SQL Server实例 Instance3，该实例是一个独立实例。
在 NODE01上，Marcel 为 Always On 可用性组启用了 fciInstance1。 在 NODE02上，他为 Instance3 启用了 Always On 可用性组。 然后，他设置了一个可用性组，其中 fciInstance1 承载主副本， Instance3 承载辅助副本。
在某些时候，fciInstance1 会在 NODE01 上变得不可用，并且 WSFC 会导致 fciInstance1 故障转移到 NODE02。 在故障转移后， fciInstance1 将是启用了 Always On 可用性组的实例并且在 NODE02上以主角色运行。 但是， Instance3 现在驻留在与 fciInstance1相同的 WSFC 节点上。 这违反了 Always On 可用性组 约束。
若要纠正此方案产生的问题，独立实例 Instance3 必须驻留在与 NODE01 和 NODE02 相同的 WSFC 中的另一个节点上。

有关 SQL Server FCI 的详细信息，请参阅 Always On 故障转移群集实例 (SQL Server)。

将 WSFC 故障转移群集管理器用于可用性组的限制

不要使用故障转移群集管理器来操作可用性组，例如：

• 不要在可用性组的群集服务（资源组）中添加或删除资源。

• 不要更改任何可用性组属性，例如可能的所有者和首选所有者。 这些属性由可用性组自动设置。

• 不要使用故障转移群集管理器将可用性组移到不同节点或者故障转移可用性组。 故障转移群集管理器不知道可用性副本的同步状态，因此，这样做可能会导致延长停机时间。 必须使用 Transact-SQL 或 SQL Server Management Studio。

警告

使用故障转移群集管理器将托管可用性组的故障转移群集实例移动到已在托管同一个可用性组副本的节点，可能会导致可用性组副本丢失，使其无法在目标节点上重新联机。 故障转移群集的单个节点不能托管同一个可用性组的多个副本。 有关如何发生这种情况以及如何恢复的详细信息，请参阅博客在可用性组中意外删除副本。