标签: high-availability

我们遇到了一种情况，我们要迁移到新的托管设施并尝试配置我们的新数据库环境。然而，我们都不是正式的 DBA，所以我们所做的很多事情都是在尝试做出明智决定的同时猜测和阅读文章。

首先，我们目前是一家小公司，一个月要处理几十万条记录（其中大约 1/2 有图像数据）。我们正在快速发展，在发生严重故障（SAN 阵列完全瘫痪，我们在 12 小时内丢失所有内容）之后，我们正在迁移到具有更好灾难恢复能力的新托管设施。

新的托管设施将在 50 磁盘 SAN 上拥有我们的数据库。每分钟都会拍摄一张快照。如果 SAN 出现故障，快照会加载到另一个 SAN，并且服务器会自动在新的 SAN 上启动。停机时间为几分钟。

除此之外，我们还需要一个冗余的数据库设置。我们讨论了在 2 个单独的 SAN 上使用 DFS 的 Sql Server 集群，但这违反了我们必须拥有的 PCI 合规性。因此，我认为在 SAN 发生故障时，集群不会比托管公司的内置快照系统为我们带来更多的冗余。

我们正在讨论的另一个选项是使用镜像。但是，我们阅读的信息使我们相信，使用见证进行镜像会对性能影响太大。提出的一种选择是使用“Safety Off”镜像，直到我们想要执行维护，然后启动见证，一次关闭一台服务器并执行维护。然后，完成后，关闭见证服务器。这似乎两全其美，但也令人头疼。

那么现在最大的问题是 - 我们托管公司的快照系统将我们的停机时间缩短到几分钟，建议使用什么配置来提供高可用性和最佳性能？

让我们考虑在异步复制中有两个节点的 SQL Server AlwaysOn 群集。
有没有办法计算强制故障转移后丢失了多少数据？

我的意思是在时间方面，能够知道“我丢失了 1 小时的数据或 1 分钟”。我考虑过检查 LSN，但我不知道如何将它们转换为日期时间。

我正在第一次设置始终在高可用性集群上的过程。任何人都可以在配置组并测试以确保它正常运行后从网络角度向我解释，SQL 如何知道何时进行故障转移，以及我的应用程序如何连接到 SQL 服务器知道它指向哪里？

例如，我有一个foo连接到命名实例的应用程序DB01.FOO。当foo失败并转至 时DB02.FOO，我的应用程序如何知道它应该与之交谈DB02.FOO？

DB02.FOO在同一个域中，但在不同的服务器中。在尝试之前，我只是想先了解一下这方面的所有方面。如果有任何链接，有人会推荐这也很棒。

我有两个问题要问你们。我真的很感谢你的帮助。

1.- 有没有办法重命名可用性组？

2.- 有没有办法获取 T-SQL 语句以重新创建可用性组，以防我需要删除它并再次创建它？

如果您希望我分享任何信息，请告诉我，我会提供。

今天错误地从实时服务器上删除了 AlwaysOn 可用性数据库。

让我来解释细节。

在 AlwaysON 可用性组中，有 2 个可用性副本。那是

主副本服务器（即 SQLServer1）

辅助副本服务器（即 SQLServer2）

在 中Primary Replica Server，有4 个数据库。

AlwaysOnTest 
Database2
Database3
Database4

Run Code Online (Sandbox Code Playgroud)

在辅助副本服务器 (SQLServer2) 中，我不能确切地说，因为那是另一个 SQLserver。但坦率地说，我想说我无权访问该服务器。

当我获得主服务器的可访问性时，它已经由第三方供应商配置。作为一名 DBA，我的任务是备份SQLServer1. 还要备份AlwaysONTest数据库。其中AlwaysOnTest 主副本服务器（SQLServer1）的数据库与辅助副本服务器（SQLServer2）同步。这只是一个与二级副本同步的数据库。

今天在卡塔尔时间下午 12:10 误将 AlwaysOn 数据库删除。我有主服务器昨天的完整备份。注意：备份的备份首选项是Secondary Only.

在实例之后，我还对主要副本进行了完整备份。

现在我想再次AlwaysONTest使用辅助副本配置数据库。

注意：只是误删了AlwaysOn Availability 数据库。环境就是这样。

我该怎么办。任何建议或帮助将不胜感激。

我们有两个数据中心，它们之间的 ping 时间为 2 ms，通过站点到站点 VPN 连接。在主数据中心，我们有 2 台服务器，在辅助数据中心，我们有一个数据库服务器。所有服务器的规格和配置都相同，运行 Windows 2012 R2，我们有两个 SQL Server 2016 Enterprise 许可证。一种用于主站点 + 故障转移，一种用于辅助站点。

问题是我们应该使用什么技术？始终在可用性组上，在主数据中心的两个节点之间进行同步复制并异步复制到辅助数据中心。另一种选择是在主数据中心使用镜像，然后将日志传送到辅助数据中心。唯一需要注意的是，我们需要使用透明数据加密 (TDE)，因此需要使用企业许可证。

我们的运维团队目前有 2 人并且在不断增长，但还没有完全分配 DBA，我知道如何设置这两种技术，但只在生产中使用过镜像和日志传送。

人们会推荐什么，always on 看起来很棒，但我读过一些文章说你需要大量的 DBA 资源来照顾它，而镜像和日志传送要容易得多。

很多 MongoDB 教程在谈到副本集时，都给出了两台机器的示例：一台最初初始化为主要机器，另一台最初创建为辅助机器。

据我了解：

• 如果主要成员意外死亡，次要成员无论如何都不会选举自己成为新的主要成员，因为它不会拥有多数（两台机器的副本集中的两个）。

• 如果主成员不可用，即使使用read_preference=ReadPreference.SECONDARY.

• 重新创建主成员无论如何都行不通：它不能添加到现有的副本集中，因为它缺少主成员；它也不能rs.initiate();，因为它将创建具有不同 ID 的不同副本集。

因此，在现实生活中，复制集中只有两个成员是否有意义？或者这种情况只是理论上的，在实践中人们会期望在每个副本集中看到至少三个成员？

我们想要创建一个 Always On Availability 组，其中主要副本将在本地，次要副本将在 Azure VM 上。我已经研究过并且我知道这样做是可能的，但是在我发现的所有示例中，他们总是在本地也有一个辅助副本，然后第 3 个虚拟机是天蓝色的虚拟机。我们只想要 2 个副本，一个在本地，一个在 azure 上。这可能吗？

我已阅读文档以使用“添加 Azure 副本向导”，其中一个先决条件是：您的可用性组必须包含本地可用性副本。我不确定这是否意味着我必须在本地至少有一个辅助副本，还是仅意味着我必须先在本地创建可用性组，然后才添加辅助副本。

感谢您的帮助和指导！

让我在这篇文章的序言中说，我在跟踪中遗漏了一些事件，但我已经添加了它们，以便下次发生这种情况时添加它们。

最近，我们在我们的环境中看到了 HADR_SYNC_COMMIT 等待类型的奇怪激增（~40k tran/s）。今天的“事件”发生在凌晨4点58分：

在继续之前，我必须补充一点，我们正在对一个大型审计表进行在线索引维护（从 OLTP 表触发器大量记录到此审计表的意义上进行审计），并且索引重建本身被阻止约 22 秒。显然，这在这个特定实例中发挥了作用，但我不太确定它与 HADR_SYNC_COMMIT 有何关系。此外，我们在白天不进行索引维护时也看到过这种情况发生。

查看跟踪，这是我在主设备上看到的：

...以及辅助设备上的所有内容：

...最后回到主要：

2023 年 12 月 1 日凌晨 4:11 左右再次发生了类似的问题，我相信我明白发生了什么。不幸的是，我没有针对这种情况的扩展事件，但我确实有一些日志记录可以描绘出更清晰的画面。从 2023-12-01 04:10:18.5430090 开始，Ola 的索引维护记录了相关数据库上索引的开始时间。Ola 报告的完成时间为 2023-12-01 04:11:13.9431563，但我相信实际 REBUILD WITH ONLINE = ON 完成的时间要早​​得多。

在查看 DPA 时，我注意到 pagelatch_sh 和 pagelatch_ex 等待时间在凌晨 4:11:03-4:11:04 出现峰值：

紧接着这些等待，同一个查询开始看到 HADR_SYNC_COMMIT，并且这些相同的等待在凌晨 4:11:13-4:11:14 完全消失，这正是 Ola 报告索引完成的时间。我的假设是索引 REBUILD 是在凌晨 4:11:03 提交的（大约需要 45 秒的工作），这导致同一数据库中的不相关 INSERT 查询只是等待所有这些日志块在辅助数据库上硬化。一旦索引完成，剩余的日志块就会立即硬化，因为它们只是微小的插入。

我们正在使用 SQL 2008 R2 创建一个三节点三实例集群（不是最先进的，但这是应用程序支持的），并认为它应该能够在两个物理节点关闭的情况下维持仲裁。配置它的最佳方法是什么？

我的经理一直在推动一个见证服务器，它就像在节点和磁盘多数之上进行额外的法定投票。这给了我们每个节点的投票，为仲裁磁盘投票，但是是否可以设置一个接收投票的见证服务器？

我认为见证是用于镜像的，我们没有计划在这个集群上实施。有人告诉我，添加第四个节点是不可能的，即使它只是一个被动节点。