可用性组配置的高可用性和数据保护
适用于： 
SQL Server - Linux
本文介绍 Linux 服务器上的 SQL Server Always On 可用性组支持的部署配置。 可用性组支持高可用性和数据保护。 自动故障检测、自动故障转移和故障转移后的透明重新连接提供高可用性。 同步副本提供数据保护。
在 Windows Server 故障转移群集 (WSFC) 上，常见的高可用性配置使用两个同步副本和第三个服务器或文件共享来提供仲裁。 文件共享见证验证可用性组配置 - 例如，同步状态和副本的角色。 此配置可确保选作故障转移目标的次要副本具有最新的数据和可用性组配置更改。
WSFC 为可用性组副本和文件共享见证之间的故障转移仲裁同步配置元数据。 当可用性组不在 WSFC 上时，SQL Server 实例将配置元数据存储在 master 数据库中。
例如，Linux 群集上的某个可用性组具有 CLUSTER_TYPE = EXTERNAL。 没有用于仲裁故障转移的 WSFC。 在这种情况下，配置元数据由 SQL Server 实例进行管理和维护。 由于此群集中没有见证服务器，因此需要第三个 SQL Server 实例来存储配置状态元数据。 这三个 SQL Server 实例一起为群集提供分布式元数据存储。
群集管理器可以查询可用性组中的 SQL Server 实例，并协调故障转移以维持高可用性。 在 Linux 群集中，Pacemaker 是群集管理器。
SQL Server 2017 (14.x) CU 1 可为具有两个同步副本和一个仅配置副本且 CLUSTER_TYPE = EXTERNAL 的可用性组实现高可用性。 仅配置副本可以托管在 SQL Server 2017 (14.x) CU 1 或更高版本的任意版本（包括 SQL Server Express 版本）上。 仅配置副本在 master 数据库中维护有关可用性组的配置信息，但不包含可用性组中的用户数据库。
配置如何影响默认资源设置
SQL Server 2017 (14.x) 引入了 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 群集资源设置。 此设置可保证在主要副本提交每个事务之前，指定数量的次要副本将事务数据写入日志。 使用外部群集管理器时，此设置会影响高可用性和数据保护。 此设置的默认值取决于创建群集资源时的体系结构。 安装 SQL Server 资源代理 mssql-server-ha 并为可用性组创建群集资源时，群集管理器会检测可用性组配置并相应地设置 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT。
如果配置支持，则资源代理参数 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 将设置为提供高可用性和数据保护的值。 有关详细信息，请参阅了解 Pacemaker 的 SQL Server 资源代理。
以下部分解释了群集资源的默认行为。
选择一种可用性组设计，以满足高可用性、数据保护和读取扩展的特定业务需求。
以下配置描述了可用性组设计模式以及每个模式的功能。 这些设计模式适用于具有高可用性解决方案且 CLUSTER_TYPE = EXTERNAL 的可用性组。
- 三个同步副本
- 两个同步副本
- 两个同步副本和一个仅配置副本
三个同步副本
此配置包含三个同步副本。 默认情况下，它可提供高可用性和数据保护。 它还可以提供读取扩展。
具有三个同步副本的可用性组可以提供读取扩展、高可用性和数据保护。 下表对可用性行为进行了说明。
| 可用性行为 | 读取扩展 | 高可用性和 数据保护 |
数据保护 |
|---|---|---|---|
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= |
0 | 1 1 | 2 |
| 主要副本中断 | 自动故障转移。 可能导致数据丢失。 新的主要副本为 R/W 副本。 | 自动故障转移。 新的主要副本为 R/W 副本。 | 自动故障转移。 在先前的主要副本恢复并加入可用性组作为次要副本之前，新的主要副本不可用于用户更新事务。 |
| 一个次要副本中断 | 主要副本为 R/W 副本。 | 主要副本为 R/W 副本。 | 在出现故障的次要副本恢复并加入可用性组之前，主要副本不可用于用户更新事务。 |
1 默认值
两个同步副本
此配置可实现数据保护。 与其他可用性组配置一样，它可以实现读取扩展。 两个同步副本配置不提供自动高可用性。 两个副本配置仅适用于 SQL Server 2017 (14.x) RTM，不再受 SQL Server 2017 (14.x) 的更高版本（CU1 及更高版本）的支持。
具有两个同步副本的可用性组可提供读取扩展和数据保护。 下表对可用性行为进行了说明。
| 可用性行为 | 读取扩展 | 数据保护 |
|---|---|---|
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= |
0 1 | 1 |
| 主要副本中断 | 自动故障转移。 可能导致数据丢失。 新的主要副本为 R/W 副本。 | 自动故障转移。 在先前的主要副本恢复并加入可用性组作为次要副本之前，新的主要副本不可用于用户更新事务。 |
| 一个次要副本中断 | 主要副本为 R/W 副本，运行可能导致数据丢失。 | 在次要副本恢复之前，主要副本不可用于用户更新事务。 |
1 默认值
两个同步副本和一个仅配置副本
具有两个（或更多）同步副本和一个仅配置副本的可用性组除了提供数据保护，还可以提供高可用性。 下图呈现了此体系结构：
- 用户数据到次要副本的同步复制。 它还包括可用性组配置元数据。
- 可用性组配置元数据的同步复制。 它不包括用户数据。
在可用性组关系图中，主要副本将配置数据推送到次要副本和仅配置副本。 次要副本还接收用户数据。 仅配置副本不接收用户数据。 次要副本处于同步可用性模式。 仅配置副本不包含可用性组中的数据库 - 仅包含有关可用性组的元数据。 仅配置副本上的配置数据是同步提交的。
注意
具有仅配置副本的可用性组是 SQL Server 2017 (14.x) CU 1 的新增功能。 可用性组中的所有 SQL Server 实例都必须为 SQL Server 2017 (14.x) CU 1 或更高版本。
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的默认值为 0。 下表对可用性行为进行了说明。
| 可用性行为 | 高可用性和 数据保护 |
数据保护 |
|---|---|---|
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= |
0 1 | 1 |
| 主要副本中断 | 自动故障转移。 新的主要副本为 R/W 副本。 可能导致数据丢失。 | 自动故障转移。 新的主要副本不可用于用户更新事务。 |
| 次要副本中断 | 主要副本为 R/W 副本，运行可能导致数据丢失（如果主要副本发生故障且无法恢复）。 如果主要副本也发生故障，则不进行自动故障转移。 | 主要副本不可用于用户更新事务。 如果主要副本也发生故障，则没有可以将故障转移到的副本。 |
| 仅配置副本中断 | 主要副本为 R/W 副本。 如果主要副本也发生故障，则不进行自动故障转移。 | 主要副本为 R/W 副本。 如果主要副本也发生故障，则不进行自动故障转移。 |
| 同步次要副本 + 仅配置副本中断 | 主要副本不可用于用户更新事务。 不进行自动故障转移。 | 主要副本不可用于用户更新事务。 如果主要副本也发生故障，则没有可以将故障转移到的副本。 |
1 默认值
注意
托管仅配置副本的 SQL Server 实例也可以托管其他数据库。 它还可以作为仅配置数据库参与到多个可用性组中。
要求
- 具有仅配置副本的可用性组中的所有副本都必须为 SQL Server 2017 (14.x) CU 1 或更高版本。
- 任何版本的 SQL Server 都可以托管仅配置副本，包括 SQL Server Express。
- 除主要副本外，可用性组还需要至少一个次要副本。
- 仅配置副本不计入每个 SQL Server 实例的最大副本数。 SQL Server Standard Edition 最多允许 3 个副本，SQL Server Enterprise Edition 最多允许 9 个副本。
注意事项
- 每个可用性组只能有一个仅配置副本。
- 仅配置副本不能是主要副本。
- 无法修改仅配置副本的可用性模式。 若要将仅配置副本更改为同步或异步次要副本，请删除仅配置副本，并添加具有所需可用性模式的次要副本。
- 仅配置副本与可用性组元数据同步。 没有用户数据。
- 具有一个主要副本和一个仅配置副本但没有次要副本的可用性组是无效的。
- 无法在 SQL Server Express 版本的实例上创建可用性组。
了解 Pacemaker 的 SQL Server 资源代理
SQL Server 2017 (14.x) 引入了 sequence_numbersys.availability_groups，以显示标记为 SYNCHRONOUS_COMMIT 的副本是否是最新的。 sequence_number 是一个单调递增的 BIGINT，表示本地可用性组副本相对于可用性组中其余副本的新旧程度。 执行故障转移、添加或删除副本以及其他可用性组操作会更新此数字。 该数字将在主要副本上更新，然后推送到次要副本。 因此，处于最新状态的次要副本的 sequence_number 与主要副本相同。
当 Pacemaker 决定将某个副本升级为主要副本时，首先会向所有副本发送通知，以提取并存储序列号（此通知被称为预升级通知）。 接下来，当 Pacemaker 尝试将某个副本升级为主要副本时，如果该副本的序列号在所有副本的序列号中是最高的，则该副本只会升级自身，否则它将拒绝提升操作。 这样，就只有序列号最高的副本才会升级为主副本，确保不会丢失数据。
仅当至少一个可用于提升的副本与前一个主副本具有相同的序列号时，才能保证提升有效。 默认行为是，Pacemaker 资源代理自动设置 REQUIRED_COPIES_TO_COMMIT，从而使至少一个同步提交次要副本处于最新状态且可用作自动故障转移的目标。 对于每个监视操作，REQUIRED_COPIES_TO_COMMIT 的值按“同步提交副本数/2”的方式进行计算（如果需要，也将进行更新）。 然后，在故障转移时，此资源代理需要一定数量的副本（total number of replicas - required_copies_to_commit 个副本）响应预升级通知，从而能够将其中一个副本升级为主要副本。 sequence_number 最高的副本提升为主要副本。
例如，让我们考虑这样一种情况：某个可用性组具有三个同步副本 - 一个主要副本和两个同步提交次要副本。
REQUIRED_COPIES_TO_COMMIT为 3 / 2 = 1响应预升级操作所需的副本数为 3 - 1 = 2。 因此需准备 2 个副本来触发故障转移。 当发生主要副本中断时，如果其中一个次要副本无响应，并且只有一个次要副本响应预提升操作，则资源代理无法保证响应的次要副本具有最高的
sequence_number，从而不会触发故障转移。
用户可选择替代默认行为，不采用前面显示的设置，而将可用性组资源配置为不自动设置 REQUIRED_COPIES_TO_COMMIT。
重要
REQUIRED_COPIES_TO_COMMIT 为 0 时有数据丢失风险。 在主要副本中断的情况下，资源代理不会自动触发故障转移。 用户必须决定是等待主要副本恢复还是手动执行故障转移。
要将 REQUIRED_COPIES_TO_COMMIT 设置为 0，请运行：
sudo pcs resource update <ag_cluster> required_copies_to_commit=0
（SLES 上）使用 crm 的等效命令为：
sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0
若要还原为默认计算值，请运行：
sudo pcs resource update <ag_cluster> required_copies_to_commit=
注意
更新资源属性会导致所有副本停止并重启。 这意味着主要副本将暂时降级为次要副本，然后再次升级，这将导致临时写入不可用。 REQUIRED_COPIES_TO_COMMIT 的新值仅在副本重新启动后进行设置，因此不会与运行 pcs 命令同时进行。
在高可用性和数据保护之间进行平衡
上述默认行为也适用于 2 个同步副本（主副本 + 次要副本）的情况。 Pacemaker 默认为 REQUIRED_COPIES_TO_COMMIT = 1，从而确保次要副本始终处于最新状态，实现最大程度的数据保护。
警告
由于次要副本发生计划内或计划外中断，该操作会增加主要副本不可用的风险。 用户可选择更改资源代理的默认行为，并将 REQUIRED_COPIES_TO_COMMIT 替换为 0：
sudo pcs resource update <ag1> required_copies_to_commit=0
替换后，资源代理将新设置用于 REQUIRED_COPIES_TO_COMMIT，并对其停止计算。 用户必须相应地手动更新它（例如，如果他们增加了副本数）。
下表描述了在不同可用性组资源配置中，主要副本或次要副本发生中断时的后果：
可用性组 - 2 个同步副本
| 配置 | 主要副本中断 | 一个次要副本中断 |
|---|---|---|
REQUIRED_COPIES_TO_COMMIT = 0 |
用户必须发出手动 FAILOVER。可能导致数据丢失。 新的主要副本是 R/W |
主要副本为 R/W 副本，运行可能导致数据丢失。 |
REQUIRED_COPIES_TO_COMMIT = 1 1 |
群集自动发出 FAILOVER无数据丢失。 在先前的主要副本恢复并加入可用性组作为次要副本之前，新的主要副本将拒绝所有连接。 |
次要副本恢复之前，主要副本将拒绝所有连接。 |
1 Pacemaker 的 SQL Server 资源代理默认行为。
可用性组 - 3 个同步副本
| 配置 | 主要副本中断 | 一个次要副本中断 |
|---|---|---|
REQUIRED_COPIES_TO_COMMIT = 0 |
用户必须发出手动 FAILOVER。可能导致数据丢失。 新的主要副本是 R/W |
主要副本为 R/W 副本 |
REQUIRED_COPIES_TO_COMMIT = 1 1 |
群集自动发出 FAILOVER。无数据丢失。 新的主要副本为 RW 副本 |
主要副本为 R/W 副本 |
1 Pacemaker 的 SQL Server 资源代理默认行为。