标签: availability-groups

我正在考虑使用 SQL Server 2012 中的 SQL Server 可用性组将我们主数据库上的报告卸载到第二个只读服务器，该服务器通过可用性组保持同步。

我的问题是，当我在只读服务器上运行大型报告时，如果在读/写版本上运行通常会产生大量阻塞，锁是否会从只读服务器传播回读/写服务器？还是锁只保留在只读服务器上，只会导致等待同步的数据阻塞？

尝试查看拥有只读服务器是否可以解决我遇到的一些问题。

我是微软技术的新手，我在 SQL Server 2014 的连接部分遇到了问题。这可能是一个简单的问题，但我被卡住了。

我有4台服务器。其中之一是 Active Directory 域控制器，一个是应用程序服务器，另一个用于 SQL Server。由于这是一个连接问题，服务器的 IP 是； -AD DC：10.6.0.100（也是 DNS 服务器） -APP：10.6.0.110 -SQL 1：10.6.0.120 -SQL 2：10.6.0.121

我已经成功创建了一个故障转移集群 (DBCLUSTER) 并将 FC 的 IP 地址设置为10.6.0.130（这不是实际的服务器 IP，我真的不明白这部分..）。

后来，我为 sql 服务器创建了一个 AlwaysOn 可用性组。我已经成功创建了没有侦听器的 AG。我可以从彼此连接到服务器，数据库同步没有问题。然后，我创建了一个监听器（AG侦听），并设置它的IP为10.6.0.131（这是不实际的服务器IP，再？）和它的端口设置为5525。它没有给任何问题。

所以我想测试连通性。当我想从APP服务器直接连接到SQL 1或SQL 2 时，我可以毫无问题地连接。但是当我尝试连接到AG-LISTENER 时，它在网络上找不到它。当我检查 DNS 记录时。我可以看到它托管在10.6.0.131 上。

当我尝试从AD-DC、APP、SQL 2服务器ping AG-LISTENER 时，它响应目标主机无法访问（它正在 ping 10.6.0.131，但响应来自 AD-DC、APP …

我们有一个在 Windows Server 2012 R2 上运行 SQL Server 2012 的双节点集群设置。基础集群仅由这两个节点组成。仲裁设置为节点 + 磁盘多数，共享磁盘位于通过 iSCSI 连接的 EqualLogic 阵列上。集群配置验证没有错误。

今天早些时候，集群上运行的两个可用性组（节点 #1 上的主节点）在两个节点上都进入了解决状态。查看集群事件，在它尝试重新启动服务之前什么也没有。Windows 故障转移群集下的所有内容都显示为绿色（在线且无警告） - 磁盘、网络接口、节点等。

查看 Windows 事件查看器中的应用程序日志，由于无法建立仲裁，群集已请求显示可用性组正在进入解决状态的事件。我在任何日志中找不到任何其他内容来支持这一点，并且在集群验证期间仲裁通过。

AG 不会恢复。我们在 SQL Server 日志中的 AlwaysOn 日志中发现，第一个节点出现了镜像端点故障。这在内存访问冲突后立即发生，其症状类似于 Microsoft 已通过累积更新 6 解决的问题，因此我们将在接下来尝试。

我能够重新启动节点 1 上的 SQL Server 服务（第二个注释无法与之通信的内存访问冲突），并且我能够在那时使可用性组重新联机。重新启动也会使一切恢复到 100%。

您是否有任何见解，为什么当镜像端点失败时，节点 1 不会发生故障并让数据库在节点 2 上保持活动状态？我们目前处于 AG 3 级；将其提高到 4 会触发节点 1 上的故障，同时让节点 2 上的服务保持活动状态吗？

我们的所有生产数据库都采用简单恢复模型，对此我们感到非常高兴，因为它完全满足我们的 RPO 和 RTO。

现在我们想为我们的数据库实施 AG DR 解决方案，我们发现完全恢复模型是一个要求。

我的问题是为什么？从理论上讲，AG 或其他 SQL Server DR 解决方案（日志传送、数据库镜像）不应该与简单恢复模型一起使用是否存在任何技术原因？

我正在寻找有关在 Windows Server 2012 R2 上构建 SQL Server 2016 SP1 Always On Availability Groups HADR 解决方案的一些指导。我们有一个带有主副本和辅助副本的主站点 A 和一个带有辅助副本和文件共享见证的灾难恢复 (DR) 站点 B。我们的目标是，如果站点 A 的主副本服务器 1 发生故障，则 Always On Availability Group (AG) 故障转移到站点 A 的辅助副本服务器 2，如果站点 A 的两台服务器都发生故障，则 AG 故障转移到站点 B。

我们正在尝试按照https://technet.microsoft.com/en-us/library/cc731739(v=ws.11).aspx和此图表进行节点和文件共享多数配置：

此图显示，当一个节点和“磁盘”/文件共享见证通信时，集群运行，但在我们对这种情况的测试中，由于 WSFC 的仲裁丢失，集群失败。如果我们通过禁用 vmWare 中的 NIC 一次测试一台服务器的故障，则自动 AG 故障转移会起作用，因为 SQL Server 2016 支持两个自动故障转移目标副本。但是，如果我们同时使站点 A 的两台服务器发生故障以模拟点对点网络故障或站点电源故障，则不起作用。

以下手动干预强制仲裁的方法将起作用，但它不是自动的，这是我们在理想情况下想要的：

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode –Name $node –FixQuorum

ALTER AVAILABILITY GROUP SQLServerAO FORCE_FAILOVER_ALLOW_DATA_LOSS;

$node = "SQLServerC"
Stop-ClusterNode –Name $node
Start-ClusterNode …

简单的问题（我希望！）

为什么要为 Always On AG 侦听器使用非默认端口？

我还没有找到一个很好的帖子（还）概述优点与缺点。

目前，我可以想到使用 1433 以外的其他三个原因：

• 遵循 Sql Server 安全加固指南。
• 避免端口冲突（根据https://msdn.microsoft.com/en-us/library/hh213417.aspx#SelectListenerPort）。
• 能够在网络跟踪等中更快地识别对特定 AG 的数据库调用。

有没有其他人能想到的？

在AlwaysOn 可用性组(AG) 和AlwaysOn 故障转移群集实例(FCI) 的整个 MS 文档中，我看到以下模式：

1. FCI 适用于 HA 场景。
2. 与主副本位于同一位置的 AG 同步辅助副本适用于 HA 方案。
3. 位于不同数据中心的 AG 异步辅助副本用于 DR 场景。

这是讨论此问题的示例 MS 链接。

由于选项 #1 和 #2 都适用于 HA 方案，我该如何在它们之间做出决定？如果 MS 发布了 #1 和 #2 的成本和 RPO/RTO 指标，就很容易决定我想要哪个。

或者也许有一种不同的方式来理解这些选项之间的投资回报率差异。例如，也许选项 #2 最适合 VLDB，而选项 #1 最适合非常高的交易量。我不知道。

那么，DBA 用于在选项 #1 和 #2 之间进行选择的选择标准是什么？

更复杂的是，我知道选项 #1 和 #2 可以结合使用！什么时候结合这两种选择是明智的？什么时候结合这两个选项毫无意义？我知道当这些选项组合在一起时，AG 不再支持自动故障转移。这是有趣的琐事，但没有回答我的问题。

顺便说一下，我打算将我的最终解决方案供应到 Azure IaaS。如果我使用 Always On FCI，我可能会使用 Storage Spaces Direct (S2D) 创建准 SAN。

更新

我找到了两篇文章进行了比较。第一个是MS …

我们真的需要在配置了 Always On 同步更新的数据库上运行 DBCC checkdb 吗？

我相信自动页面修复机制应该识别损坏并自动修复它。

第一次打电话，长时间的听众。

我有一种情况，我需要在大约 2 个月内建立一个服务器可用性组（即将数据库移动到新服务器，重建当前服务器，并将重建的当前服务器添加到 AG）。两台服务器都是物理服务器，并且具有大致相同的规格。Windows Server 2016、SQL Server 2014。

我的想法是现在用监听器来支持 AG，这样当当前服务器被重建并添加到组中时，我们不需要添加监听器然后更新我们所有的应用程序/客户端（即这将强制两个迁移，一个到新的服务器，一个到新的监听器）。

我已经在一些测试服务器上测试了这种情况，并且它按预期工作。我也无法预见不这样做的理由，但我认为值得社区询问，因为我们正在谈论生产数据库。我的问题是有人试过这个并且有任何问题吗？有人会建议反对这个解决方案。谢谢。

我有两台服务器始终处于故障转移配置中，下面是 Windows 集群。

两台服务器需要有相同的内存吗？
我们使用大量内存的数据库之一不在 AG 中，因此理想情况下，我不想为辅助服务器提供与主服务器相同的内存，因为 - 它永远不需要运行大数据库。