以下来自AlwaysOn官方文档，以最新的SQL Server 2019 On Windows为准，也学习下相关新特性。不会完全按照官方文档翻译，有删改。
针对 AlwaysOn 可用性组的先决条件、限制和建议
本文介绍部署 AlwaysOn 可用性组时的注意事项，包括针对主机、WSFC、SqlServer实例和可用性组的先决条件、限制和建议。 还指出了对应的安全注意事项和所需权限（如果有）。在部署 AlwaysOn 可用性组前，强烈建议您阅读本主题的每个章节。
一、 支持可用性组的 .Net Hotfixes
根据您将使用的AlwaysOn 可用性组的组件和功能，您可能需要安装下表中.Net Hotfixes（表中Hotfixes安装顺序不限）
| Dependent Feature | Hotfix | Link |
|---|---|---|
| Reporting Services | Hotfix for .Net 3.5 SP1添加了对SQL Client for AlwaysOn的读意向、只读和多子网故障转移功能的支持。 此Hotfix应安装在每个Reporting Services报表服务器上。 | KB 2654347：.Net 3.5 SP1 修补程序添加对 AlwaysOn 功能的支持 |
二、 基本要求（Windows 系统）
为了支持 AlwaysOn 可用性组功能，请确保要参与可用性组的每台计算机都满足以下要求：
| 要求 | 链接 |
|---|---|
| 确保此系统不是域控制器。 | 域控制器上不支持可用性组。 |
| 确保每台计算机操作系统版本不低于Windows Server 2012。 | 安装 SQL Server 2016 的硬件和软件要求 |
| 确保每台计算机都是WSFC中的一个节点。 | Windows Server 故障转移群集 (WSFC) 与 SQL Server |
| 确保WSFC包含足够的节点来支持可用性组配置。 |
|
三、 关于可用性副本主机的建议（Windows 系统）
-
类似的系统： 所有可用性副本主机性能配置应该相近，能够处理相近的负载。
-
专用网络适配器： 为获得最佳性能，请给AlwaysOn 可用性组使用专用的网络适配器（网络接口卡）。
-
足够的磁盘空间： 可用性副本主机必须拥有足够的磁盘空间。 在主数据库增长时，相应的辅助数据库也增长相同量。
1. 权限（Windows 系统）
若要管理 WSFC，用户必须是每个群集节点上的系统管理员（system administrator）。
有关用于管理群集的帐户的详细信息，请参阅附录 A：故障转移群集要求。
2. 相关任务（Windows 系统）
| 任务 | 链接 |
|---|---|
| 设置 HostRecordTTL 值。 | 更改 HostRecordTTL（使用 Windows PowerShell） |
步骤如下：
-
通过 “以管理员身份运行” 打开 PowerShell 窗口。
-
导入 FailoverClusters 模块。
-
使用 Get-ClusterResource cmdlet 查找网络名称资源，然后使用 Set-ClusterParameter cmdlet 设置 HostRecordTTL 值
Get-ClusterResource “<NetworkResourceName>” | Set-ClusterParameter HostRecordTTL <TimeInSeconds>下面的示例 为名为SQL Network Name(SQL35)的网络名称资源将HostRecordTTL设置为 300 秒。
Import-Module FailoverClusters
$nameResource = "SQL Network Name (SQL35)"
Get-ClusterResource $nameResource | Set-ClusterParameter ClusterParameter HostRecordTTL 300
四、 SQL Server 实例先决条件和限制
SQL Server 实例既可以是单实例也可以是故障转移群集实例 (FCI)。
1. 先决条件
| 先决条件 | 链接 |
|---|---|
| Windows Server 故障转移群集 (WSFC) 与 SQL Server 故障转移群集和 AlwaysOn 可用性组 (SQL Server) 分布式可用性组（AlwaysOn 可用性组） |
如果您希望将可用性组与 Kerberos 一起使用：
| 为 Kerberos 连接注册服务主体名称
|
| 如果计划使用故障转移群集实例 (FCI) 承载可用性副本，则请确保您理解FCI限制并且满足 FCI 要求。 | 使用 SQL Server 故障转移群集实例 (FCI) 承载可用性副本的先决条件和要求（本文后面将作介绍） |
| 所有服务器实例必须运行相同版本的 SQL Server | SQL 2014、SQL 2016 和 SQL 2017 的各版本和支持的功能。 |
| 所有服务器实例必须使用相同的SQL Server排序规则 | 设置或更改服务器排序规则 |
| 为所有要承载可用性副本的服务器实例都启用 AlwaysOn可用性组功能 | 启用和禁用 AlwaysOn 可用性组 (SQL Server) **重要提示** 如果销毁并重新创建了 WSFC，则必须在每个服务器实例上禁用并重新启用AlwaysOn可用性组功能。 |
** 安全说明 ** AlwaysOn 可用性组 的传输安全性与数据库镜像的传输安全性相同。 | 数据库镜像终结点 (SQL Server) 针对数据库镜像和 AlwaysOn 可用性组的传输安全性 (SQL Server) |
| 如果要将使用了FILESTREAM的任何数据库添加可用性组，请确保在每个服务器实例上都启用了FILESTREAM。 | 启用和配置 FILESTREAM |
| 如果要将任何包含数据库（contained databases，不知道是啥，后面查一下）添加到可用性组，请确保在每个服务器实例上都设置contained database authentication为1 。 | contained database authentication 服务器配置选项 服务器配置选项 (SQL Server) |
2. 可用性组的线程使用情况
AlwaysOn 可用性组 的工作线程具有以下要求：
-
在空闲的SQL Server实例上， AlwaysOn可用性组使用0线程。
-
可用性组使用的最大线程数为 max worker threads减40。
给定服务器实例上承载的可用性副本共享一个线程池。
线程是按需共享的，如下所示：
-
一般情况下，存在 3–10 个共享线程，此数目会根据主副本工作负荷增加。
-
如果线程空闲一段时间，它会被释放回常规 SQL Server 线程池。 正常情况下，空闲线程会在处于inactive状态15 秒后释放。 但是根据上一次活动情况，空闲线程也可能保留更长时间。
-
对于次要副本，SQL Server 实例最多使用100个线程进行并行redo。每个数据库最多使用CPU核数的一半，但每个数据库不能超过16个线程。 如果单个实例的所需线程总数超过100，SQL Server 会为其余的每个数据库使用单个redo线程（详见备注）。 串行redo线程将在处于inactive状态约15秒后释放。
备注
SQL Server基于升序的数据库ID来选择使用单线程的数据库，因此，对于可用性组数据库数量>可用工作线程数量的 SQL Server 实例，应考虑其数据库创建顺序。 例如，在具有32核CPU或更多系统上，可用性组中的前六个数据库（按数据库ID升序）将使用并行重做模式，所有后续数据库将使用单个重做模式（单个redo线程）。
此外，可用性组使用未共享的线程如下：
-
每个主副本为每个主数据库使用1个日志捕获线程。 此外，它为每个辅助数据库使用1个日志发送线程，日志发送线程将在处于不活动状态 15 秒后释放。
-
辅助副本上的备份将在备份期间hold主副本上的一个线程。
有关详细信息，请参阅 Always On - HADRON 学习系列：启用了 HADRON 的数据库的工作线程池用法（CSS SQL Server 工程师博客）。
3. 权限
| 任务 | 所需的权限 |
|---|---|
| 创建数据库镜像端点 | 要求具有 CREATE ENDPOINT 权限，或者具有 sysadmin 固定服务器角色的成员身份。 此外，还要求 CONTROL ON ENDPOINT 权限。 有关详细信息，请参阅 GRANT 终结点权限 (Transact-SQL)。 |
| 启用 AlwaysOn 可用性组 | 要求本地计算机上“管理员”组中的成员身份，以及对 WSFC 的完全控制 。 |
4. 相关任务
五、 网络连接建议
强烈建议为 WSFC 节点之间的通信和可用性副本之间的通信使用相同的网络链接。 如果某些链接失败（甚至间歇性断开），使用不同的网络链接可能会导致预期外的行为。
例如，要使可用性组支持自动故障转移，辅助副本必须处于SYNCHRONIZED状态。 如果到此辅助副本的网络链接失败（甚至间歇性断开），副本将进入UNSYNCHRONIZED状态，且在该网络恢复之前无法重新同步，此时不会发生自动故障转移。
六、 客户端连接支持
有关 AlwaysOn 可用性组 支持客户端连接的详细信息，请参阅 AlwaysOn 客户端连接 (SQL Server)。
七、 可用性组先决条件和限制
1. 限制
-
可用性副本必须由WSFC的不同节点承载 ：唯一的例外是在迁移到另一个群集时，一个可用性组可能会暂时跨两个群集。
同一物理计算机上的多个虚拟机可分别为同一可用性组承载可用性副本，因为每个虚拟机都充当一个单独的计算机。
-
唯一的可用性组名称： 每个可用性组名称在WSFC上必须唯一，可用性组名称的最大长度为128个字符。
-
可用性副本： 每个可用性组都支持一个主副本和最多八个辅助副本。 可以所有副本都在异步提交模式下运行，或者最多三个副本（一主两从）在同步提交模式下运行。
-
每台计算机的可用性组和可用性数据库的最大数目 ：计算机上可放置的数据库和可用性组的实际数目取决于硬件和工作负荷，但是没有强制限制。 Microsoft 已测试每台物理机可多达 10 个 AG 和 100 个数据库。系统过载的现象包括但不限于工作线程用尽、可用性组系统视图和 DMV响应时间很长和/或调度程序系统转储停滞。 请务必用接近生产的工作负荷彻底测试您的环境，确保它可以应对您的应用程序 SLA 内的工作负荷蜂值。 考虑 SLA 时，确保考虑故障条件下的负荷以及期望的响应时间。
-
不要使用故障转移群集管理器来操作可用性组。FCI的状态在 SQL Server 和WSFC之间共享，且SQL Server保留的实例状态信息的详细程度超出群集所需。集群管理模型是：SQL Server 必须驱动事务，并负责使群集状态视图与 SQL Server的状态视图保持同步。 如果在SQL Server外部更改了群集的状态，可能导致在状态WSFC和SQL Server之间不同步，这可能会导致意外行为。
例如：
-
不要更改任何可用性组属性，例如可能的所有者。
-
不要使用WSFC来故障转移可用性组，必须使用Transact-SQL或SSMS。
-
2. 先决条件
在创建或重新配置可用性组时，请确保遵守以下要求。
| 先决条件 | 描述 |
|---|---|
| 如果您计划使用FCI承载可用性副本，请确保理解 FCI 限制并且满足 FCI 要求。 | 有关使用 SQL Server 故障转移群集实例 (FCI) 承载可用性副本的先决条件和限制（本文前面已予以介绍） |
3. 安全性
-
从WSFC继承安全性。WSFC为整个群集提供两级用户安全性：
-
只读访问
-
完全控制：在SQL Server 实例上启用 AlwaysOn可用性组需要对群集的完全控制权限。不能直接在群集管理器中添加或删除服务器实例安全性。要管理群集安全性会话，请使用 SQL Server 配置管理器或WMI。
-
-
SQL Server的每个实例都必须具有访问注册表、群集等的权限。
-
建议为各可用性副本之间的连接使用加密。
4. 权限
| 任务 | 所需的权限 |
|---|---|
| 创建可用性组 | 需要 sysadmin 服务器角色的成员资格，以及 CREATE AVAILABILITY GROUP 服务器权限、ALTER ANY AVAILABILITY GROUP 权限或 CONTROL SERVER 权限。 |
| 更改可用性组 | 对可用性组要求 ALTER AVAILABILITY GROUP 权限、CONTROL AVAILABILITY GROUP 权限、ALTER ANY AVAILABILITY GROUP 权限或 CONTROL SERVER 权限。 此外，将数据库联接到可用性组要求具有 db_owner 固定服务器角色的成员身份。 |
| 删除可用性组 | 对可用性组要求 ALTER AVAILABILITY GROUP 权限、CONTROL AVAILABILITY GROUP 权限、ALTER ANY AVAILABILITY GROUP 权限或 CONTROL SERVER 权限。
若要删除并非在本地副本上承载的可用性组，您需要针对该可用性组的 CONTROL SERVER 权限或 CONTROL 权限。 |
5. 相关任务
八、 可用性数据库先决条件和限制
1. 要求
为了符合添加到可用性组的条件，数据库必须：
| 要求 | 链接 |
|---|---|
| 是用户数据库。 系统数据库无法加入可用性组。 | |
| 位于创建可用性组的SQL Server 实例上，并且对于实例可访问。 | |
| 是读写数据库。 只读数据库不能添加到可用性组。 | sys.databases (is_read_only = 0) |
| 是多用户模式数据库。 | sys.databases (user_access = 0) |
| 未使用 AUTO_CLOSE。 | sys.databases (is_auto_close_on = 0) |
| 使用完整恢复模式。 | sys.databases (recovery_model = 1) |
| 拥有至少一个完整的数据库备份（将数据库设置为完整恢复模式之后，将需要一个完整的备份来启动完整恢复日志链） | 创建完整数据库备份 (SQL Server) |
| 不属于任何现有可用性组。 | sys.databases (group_database_id = NULL) |
| 不是为数据库镜像配置的。 | sys.database_mirroring （如果数据库未参与镜像，则所有带有“mirroring_”前缀的列将为 NULL。） |
| 如果要将使用了FILESTREAM的任何数据库添加可用性组，请确保在每个服务器实例上都启用了FILESTREAM。 | 启用和配置 FILESTREAM |
| 如果要将任何包含数据库（contained databases，不知道是啥，后面查一下）添加到可用性组，请确保在每个服务器实例上都设置contained database authentication为1 。 | contained database authentication 服务器配置选项 服务器配置选项 (SQL Server) |
备注：AlwaysOn 可用性组可使用任何受支持的数据库兼容性级别。
2. 限制
-
不能删除当前已属于可用性组的数据库。
-
如果辅助数据库的文件路径不同于相应主数据库路径，则会有以下限制：
-
新建可用性组向导/将数据库添加到可用性组向导： 不支持“Full”选项（选择初始数据同步页页面）
-
RESTORE WITH MOVE： 要创建辅助数据库，在辅助副本必须使用RESTORED WITH MOVE还原数据库文件。
-
对添加文件操作的影响 ：以后针对主副本的添加文件操作在辅助数据库上可能会失败。这可能导致辅助数据库暂停，进而导致辅助副本变为“非同步”状态。
-
备注：如何处理失败的添加文件操作的详细信息，请参阅添加文件操作失败的故障排除（AlwaysOn 可用性组）。
2. 受TDE保护的数据库
参考 https://blog.csdn.net/Hehuyi_In/article/details/102926952 与 https://blog.csdn.net/Hehuyi_In/article/details/102926967
3. 权限
需要对数据库拥有 ALTER 权限
4. 相关任务
| 任务 | 项目 |
|---|---|
| 准备辅助数据库（手动） | 为可用性组手动准备辅助数据库 (SQL Server) |
| 将辅助数据库联接到可用性组（手动） | 将辅助数据库联接到可用性组 (SQL Server) |
| 修改可用性数据库的数目 | 将数据库添加到可用性组 (SQL Server) 将辅助数据库从可用性组删除 (SQL Server) 将主数据库从可用性组删除 (SQL Server) |
扫一扫
7113
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
