标签: high-availability

首先我不得不说这个问题来自软件工程师的角度。不幸的是，我们没有 DBA，所以我们需要管理我们自己的数据库。

我们安装了 SQL Server 2012 Enterprise 来运行一个应该 24/7 可用的数据库。数据库大约 150 GB，一些表包含数十亿行。多个服务每分钟访问数据库数千次，以插入实时测量数据。所以当数据库宕机半小时，测量数据丢失半小时，这是我们承受不起的……

在这种情况下，我们有两个主要问题：

1. 我们何时以及如何安装 Microsoft 更新？
2. 我们如何应用架构更改？

我认为 Windows 更新不需要进一步解释。当新需求出现或现有需求发生变化时，我们有时需要进行一些架构更改。例如添加一些额外的列、更改数据类型、调整 varchar 字段的大小等。其中一些更改需要很长时间才能运行，甚至超时，因为数据库始终处于高负载下。

我们正在考虑安装一个额外的实例并启用 AlwaysOn，以完成以下操作：

1. 对于 Windows 更新，关闭一台服务器，安装 Windows 更新，重新启动，然后更新第二个实例。
2. 对于架构更改，关闭一台服务器，应用架构更改，将其恢复，然后将相同的更改应用于第二个实例。

这两件事可以通过 SQL Server AlwaysOn 来完成，这是一种常见的方法吗？数据甚至会在之后同步吗？还是我完全在考虑错误的方向，是否有更好的解决方案？

我正在建立一个基于三台 SQL Server 2008 R2 机器和数据库镜像的 HA SQL 服务器环境。

我会命名它们：

• 委托人.company.intra
• mirror.company.intra
• 证人.company.intra

“company.intra”域是控股公司的域。

两个数据库引擎都在侦听静态 52002 端口，因此客户端应用程序可以通过以下方式访问它们：

principal.company.intra,52002 & mirror.company.intra,52002

端点EP_Mirroring在主体和镜像、EP_Witness见证和侦听主体的 5022 端口、镜像的 5023 和见证的 5024 端口上调用。

服务帐户已正确配置并被授予对彼此端点的连接权限。

镜像功能工作正常，并且在 TSQL 手动故障转移或模拟系统故障的情况下，数据库可以正确进行故障转移。

问题在于应用程序在故障转移时行为异常。

应用程序测试上下文如下：

一个包含两个文本框和一个按钮的小型 .NET 应用程序：

单击按钮时，它会进行存储过程调用，并使用 sp 的输出填充 Textbox1，使用 my 的数据源属性填充 Textbox2 SqlConnection。

连接字符串如下所示：

Data source=principal.company.intra,52002;failover partner=mirror.company.intra,52002;
initial catalog = TEST_FAILOVER;user ID=user;password=pass;Connection Timeout=30

我从我的笔记本电脑启动了这个应用程序，位于另一个域： laptop.childcompany.com

场景一：

1. 我启动应用程序
2. 按下按钮，TB1：sp 输出/TB2：principal.company.intra,52002
3. 数据库故障转移
4. 按钮按下，连接超时
5. 按钮按下，连接超时
6. 镜像中的数据库故障转移（返回主体）
7. 按下按钮，TB1：sp 输出/TB2：principal.company.intra,52002

场景二：

1. 数据库故障转移
2. 启动应用程序
3. 按下按钮，TB1：sp 输出/TB2：mirror.company.intra,52002
4. 镜像中的数据库故障转移（回到主体）
5. 按下按钮，连接错误 …

我们进行了不同类型的基本测试，并且 AlwaysOn 通过了许多测试。我们终于对 AlwaysOn 进行了大量的写测试，它给出了令人惊讶的结果。

实际的测试详细信息在这里，目标是查看 AlwaysOn 可用性组是否可以容纳高写入负载。

1. 我有两个虚拟机，每个虚拟机都运行在 8 个内核和 17GB 的 RAM 上，分配给 SQL Server。

2. 我们编写了一个脚本来生成相当不错的写 I/O（在 20 个线程中）。

3. 每个线程基本上将 24 MB 的数据插入到一个表中，然后在无限循环中删除。

在测试运行的 15 分钟内，自动故障转移的恢复时间估计达到了 12 分钟，这是非常糟糕的。我们尝试了故障转移来确认是否真的需要 12 分钟，大约需要 5 分钟，这仍然太高了。此外，如果我们继续测试三个小时的恢复时间，ETA 几乎是 3 小时，并且在故障转移时需要几个小时才能恢复（显然，如果是集群故障转移，情况就不应该如此，因为所有事务都是已提交的事务）。

所以有几件事..

很明显，synchronous次要副本无法跟上主要正在生成的负载（即使两台机器的配置相同）。这样做的副作用是主日志将继续增长（即使我们进行日志备份，它也无法截断日志）。

我们知道辅助节点每 4 个 CPU 核心使用一个线程来执行重做，这看起来是一个明显的限制。如果主节点运行 100 个线程来生成负载，那么辅助节点无论如何都不能使用那么多线程。

此外，主要在内存中执行其所有事务，并将实际数据文件写入到检查点。但是，secondary 似乎必须从物理日志驱动器读取所有事务并重做。辅助日志池应该使这个过程更快？但是在这种情况下它做得不好。

最后向 AlwaysOn 专家提问：

1. 有谁知道这个redo过程究竟是如何发生的？
   • 它被缓存了吗？
   • 是否涉及缓冲池？

2. 二级是否使用日志池来缓存日志条目以进行重做？

3. 日志池的大小是多少？它可以增长到最大可用内存吗？

4. 当重做发生时，重做线程将页面读取到缓冲池并像正常事务一样维护它们？

5. 如果二级不能跟上怎么来AlwaysOn文章说恢复时间是几秒？

这使得可用性组的高可用性部分存在问题，因为这些恢复时间是不可持续的。

[由提问者编辑]澄清，由于人们似乎认为这已得到回答，因此主服务器上的事务确实得到了确认（即日志已硬化），因为辅助服务器的状态始终是“同步的”。所以日志的硬化不是问题。因此，在故障转移时永远需要重做过程。这意味着对于生成日志 > 重做线程容量的任何负载，AlwaysOn 将始终比没有它需要更长的时间来恢复。

我们内部拥有主 SQL Server（目前有 15 个主服务器（总共约 500 个数据库），大多数服务器具有十六进制核心处理器）。

这些被镜像到附近建筑物中的其他备份服务器（通过专用的 0ms 光纤链路）。

我们想要做的是在数英里外的异地数据中心维护我们数据的实时副本（作为更大的 DR 项目的一部分 - 即如果我们所在地区存在通信问题）。

目前我们使用 SQL Server 2008 R2 - 标准版。

显然，使用 SQL Server 2008 R2 的“标准版”将我们限制为同步镜像，因为异步是“企业版”功能。

我们已经完成了异地同步镜像的测试，但延迟使它成为不可能。

我很想升级到 SQL Server 2012 Enterprise 并实施 AlwaysOn 可用性组，但该公司不愿意花费 100,000 英镑以上来升级 SQL 许可（2012 年的每核许可 + 我们的六核处理器 = 史诗般的失败）-他们甚至不愿意花钱升级到 2008 Enterprise，所以这也是窗口之外的异步镜像。

因此，由于这些财务限制，我的手被束缚在 2008 R2 标准版上。

留给我的唯一选择是日志传送和复制（如果我遗漏了什么，请纠正我）——日志传送很粗糙——但是如果管理得当是可行的——所以我们现在把它放在次要位置。

我的问题：

1. SQL Server 2008 R2 Standard 是否具有我们进行异地复制所需的所有复制功能？
2. 在不以任何方式影响主服务器性能的情况下，将内部服务器复制到异地数据中心（20-30 毫秒延迟）是否可行（我们是否可以在“原则”服务器上设置复制分发服务器）？
3. 鉴于复制不是实例级复制解决方案 - 这是否会超过 1 个 DBA 可以处理的管理？（鉴于我已经在管理 15 台 Principle 服务器及其镜像服务器 - 诚然有很多自动化）
4. 是否可以在不影响现有镜像配置的情况下从我们的主复制 - 我的理解是最佳实践是镜像订阅服务器而不是发布服务器 - 这是正确的吗？ …

如果您参考 MSDN 文档中的Synchronous-Commit Availability Mode，您可以阅读：

在同步提交可用性模式（synchronous-commit mode）下，从库加入可用性组后，会赶上对应的主库，进入SYNCHRONIZED状态。只要数据同步继续，辅助数据库就会保持同步。这保证了在给定主数据库上提交的每个事务也已在相应的辅助数据库上提交。当给定辅助副本上的每个辅助数据库同步时，整个辅助副本的同步健康状态为 HEALTHY。

假设我有一个三节点可用性组，其中有一个处于同步HEALTHY状态的数据库。所有副本都使用同步提交模式。

另外假设，我已经配置了只读路由，以便请求ApplicationIntent=Read-Only连接到辅助副本。

如果我通过读写连接提交更改，那么很快，使用ApplicationIntent=Read-Only连接通过另一个连接选择更改的记录，我是否可以期望每次都从两个副本返回一致的结果？

编辑 - 支持已接受答案的更多信息。

在 Microsoft 技术论文“AlwaysOn: Offloading Read-Only Workloads to Secondary Replicas（Sunil Agarwal，2012 年 7 月）”中，标题数据延迟下的部分读取（强调我的）。

在辅助副本上运行的报告工作负载会产生一些数据延迟，通常为几秒到几分钟，具体取决于主要工作负载和网络延迟。即使您已将辅助副本配置为同步模式，数据延迟仍然存在。虽然同步副本确实通过在向主服务器发送 ACK 之前强化已提交事务的事务日志记录来帮助保证在理想条件下（即 RPO = 0）不会丢失数据，但它并不能保证 REDO 线程在辅助副本上确实已将关联的日志记录应用到数据库页面. 所以有一些数据延迟。您可能想知道在异步模式下配置辅助副本时是否更可能出现这种数据延迟。这是一个更难回答的问题。如果主副本和次副本之间的网络无法跟上事务日志流量（即，如果没有足够的带宽），异步副本可能会进一步落后，从而导致更高的数据延迟。在同步副本的情况下，网络带宽不足不会导致次要数据延迟更高，但会减慢主要工作负载的事务响应时间和吞吐量。

如果您的报告工作负载不能容忍任何数据延迟，您必须在主副本上运行它。好消息是，通常大多数报告工作负载都可以容忍一些数据延迟，因此可以安全地迁移到辅助副本。

虽然 Microsoft 文档的广度并不矛盾，但我觉得它可以更明确。“同步”并不意味着ACID首字母缩写词中使用的原子性和一致性。

我们有两台服务器（SQL-ATL01、SQL-ATL02）组成故障转移群集，每台服务器都作为 SQL Server 高可用性组 (HAG) 的一部分运行。每个服务器有两个网卡。一个是直接连接到另一台服务器的 10Gbit 卡，用于同步 192.168.99.x 子网上的 HAG。另一个是 1Gbit 卡，用于将 DB 服务器连接到交换机，以便与 10.0.0.x 子网上的应用服务器进行通信。侦听器指向 192.168.99.x 子网。

我们想在集群的另一个物理位置添加第三台服务器 (SQL-NYC01) 并将其作为 HAG 的异步副本部分运行，但 VPN 仅路由 1Gbit 网络子网上的流量。

有没有办法设置故障转移集群和高可用性组告诉它：

• 通过 192.168.99.x 发送 SQL-ATL01 <--> SQL-ATL02 的同步副本流量
• 在 10.0.0.x 上为 (SQL-ATL01, SQL-ATL02) <--> SQL-NYC01 发送异步副本流量

或者我们是否必须让所有副本流量在同一个 IP 地址/子网上进出？

我有一个客户，他拥有一个现有的 1.5Tb 数据仓库，目前正计划在新环境中完全更新 DW。他们的基础架构经理组织了 2 个服务器，每个服务器都采用 SQL 2017 标准，现在要求我为新的 DW 数据库/实例规划一个 HA/DR 计划。

我立即想到了使用 AlwaysOn 可用性组，尽管我以前从未使用过它们，而且我读过的文章都没有讨论典型的数据仓库工作负载——都是 OLTP 应用程序。在当前 DW 上运行大型每日 ETL 流程和较小的日内 ETL 流程时，这是否会影响我们处理此问题的方式？

谢谢 - 在这里为我指明正确方向的任何帮助都是有益的！

我知道要实现在线应用程序的某种程度的可用性，可以使用 IP 故障转移机制组织一个具有冗余的环境，并在多个相同服务器之间切换，以防其中任何一个出现问题。

但是数据库呢？数据库应该在每台服务器上，它们之间有某种复制数据，还是应该放在自己的专用服务器上？

SQL Server 2008 R2 或 SQL Server 2008 R2 Express 通常使用什么方法？

如何查看集群主节点的故障转移历史？我试图弄清楚辅助节点是在什么时候开始充当主要节点的。

我们正在运行带有 SQL Server 2012 和可用性组的 Windows Server 2012。

我正在寻找有关在 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 …