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 可用性组