SQL Server 2017 高可用性

可用性功能的使用方式主要有以下四种：

• 高可用性
• 灾难恢复
• 迁移和升级
• 扩大一个或多个数据库的可读副本

SQL Server 可用性功能不能替换对经过充分测试的可靠备份和还原策略的需求，后者是所有可用性解决方案最基本的构建基块。

AlwaysOn 可用性组

SQL Server 2012 中引入的 AlwaysOn 可用性组将数据库的每个事务发送到另一个实例，从而提供数据库级别的保护，该实例称为副本，其中包含处于特定状态的数据库副本。

副本之间的数据移动可以是同步的或异步的，Enterprise 版本允许同步多达三个副本（包括主要副本）。

AlwaysOn 是 SQL Server 中可用性功能的总称，涵盖可用性组和 FCI。 AlwaysOn 不是可用性组功能的名称。

因为可用性组只提供数据库级保护，而非实例级保护，所以需要为每个次要副本手动同步事务日志中未捕获的或数据库中未配置的任何内容.

就副本而言，Standard 版本和 Enterprise 版本具有不同的最大值。 Standard 版本中的可用性组（称为 Basic 可用性组）支持两个副本（一个主要副本和一个次要副本），且可用性组中只有一个数据库。 Enterprise 版本不仅允许在一个可用性组中配置多个数据库，而且拥有的副本总数可多达 9 个（1 个主要副本，8 个次要副本）。

 

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的同步副本时执行何种操作的行为。 该选项的工作原理如下所示：

• 有三种可能的值：0、1 和 2
• 值是必须同步的次要副本数，它对数据丢失、可用性组可用性和故障转移都有影响
• 对于 WSFC 和群集类型为“无”的情况，默认值为 0，可手动设置为 1 或 2
• 对于群集类型为“外部”的情况，该值默认由群集机制设置，并可手动重写。 对于三个同步副本，默认值为 1。 在 Linux 上，REQUIRED SYNCHRONIZED SECONDARIES_TO_COMMIT 的值在群集中的可用性组资源上配置。 在 Windows 上，则通过 Transact-SQL 设置。

大于 0 的值可确保更高的数据保护程度，因为如果无法获得所需的次要副本数，那么在该问题解决之前，主要副本不可用。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 还影响故障转移行为，因为如果适当数量的次要副本未处于正确状态，则不会发生自动故障转移。 在 Linux 上，若该值为 0 则不允许自动故障转移，因此在 Linux 上结合使用同步与自动故障转移时，该值必须设置为大于 0 才能实现自动故障转移。 在 Windows Server 上将该值设置为 0 是 SQL Server 2016 和更早版本的行为。

 SQL Server 2017 对此进行了完善，对以下两种情况都提供 DTC 支持。

• 在同一 SQL Server 实例中跨越多个数据库的事务
• 跨越多个 SQL Server 实例或可能涉及非 SQL Server 数据源的事务

 

下面的列表突出显示了 Windows Server 与 Linux 上的 FCI 之间存在的一些差异：

• 在 Windows Server 上，FCI 属于安装过程。 而 Linux 上的 FCI 则是在 SQL Server 安装完成后配置。
• Linux 仅支持每个主机安装一个 SQL Server，因此所有 FCI 都是默认实例。 Windows Server 支持每个 WSFC 具有最多 25 个 FCI。
• Linux 中 FCI 使用的公用名在 DNS 中定义，并且名称应与为 FCI 创建的资源相同。

日志传送

日志传送过程自动生成事务日志备份，并将其复制到一个或多个称为热备用状态的实例，然后自动将事务日志备份应用于该备用实例；

可以说，在某种程度上使用日志传送的最大优点在于它会考虑人为错误。 事务日志的应用可能会延迟。 因此，如果有人在没有 WHERE 子句的情况下发出类似 UPDATE 的内容，则备用可能尚未更改，如此便可在修复主系统时切换到该备用实例。

跨数据中心；

AlwaysOn 可用性组