标签: availability-groups

我想备份一个可用性组中的所有数据库，除了一个。使用 Ola 的维护解决方案脚本中的 @AvailabilityGroups 选项，是否可以从备份中排除可用性组中的单个数据库？

Always On 故障转移群集与Always On 可用性组的优势是什么？

Basic Always On Failover Clustering 提供服务器级别的保护，（例如：2 个服务器具有 1 个共享磁盘空间；如果服务器出现故障，它可以利用共享磁盘空间上的另一台服务器）。

Always On Availability Groups 提供磁盘存储灾难恢复和服务器级 HA 保护。它为 2 个服务器提供 2 个共享空间。

那么，Always On Failover Clustering 相对于 Availability Groups 在功能上有什么好处呢？查看图表比较，我没有看到。似乎可用性组更好。

我们使用SQL Server 2016 Enterprise。谢谢。

审查文件：

• 故障转移群集和 Always On 可用性组
• SQL 永远在线

Microsoft SQL Server 2012 Enterprise 常规数据库（没有 AlwaysOn）是否以任何方式具有自动页面修复功能？

我从下面知道，通过结合 AlwaysOn，辅助副本会收到自动页面修复。只是询问没有 Alwayson 的 SQL Server 数据库是否可以使用此功能？

每个 MSDN 文档https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server -2017 年，它指出

“每个可用性副本都尝试通过解决某些类型的阻止读取数据页的错误来自动从本地数据库上损坏的页面中恢复。如果次要副本无法读取页面，则副本会从主副本请求页面的新副本。如果主副本无法读取页面，则副本向所有辅助副本广播一个新副本的请求，并从第一个获取页面响应”

我在同步自动故障转移模式下配置了两个节点 SQL Server AlwaysOn 可用性组。

现在因为在同步模式下，事务需要首先在辅助副本上提交，只有在确认之后，它才会在主节点上提交。

现在，如果我的辅助副本节点出现故障，事务是否只会在我的主节点上提交，除非我的辅助节点出现？我的交易不会被硬化到磁盘吗？

我们正在使用可读的辅助副本配置可用性组。登录名可以使用其连接字符串中的“ApplicationIntent=ReadOnly”连接到辅助副本。但是我们遇到了一个问题，可能会让我们在未来头疼。

如果在登录建立连接时由于任何原因辅助副本不可用，则无论是否使用“ApplicationIntent=ReadOnly”，此登录都将被定向到主副本。

所以，我的问题 - 如果特定登录配置为使用辅助副本，是否有任何方法可以禁止它们连接到主副本？

我的意思是如果主要副本无法将连接定向到次要副本，则应关闭连接而不是继续处理主要副本。

Microsoft SQL Server 2016 (SP2-CU1) (KB4135048) - 13.0.5149.0 (X64) 2018 年 5 月 19 日 09:41:57 版权所有 (c) Microsoft Corporation Enterprise Edition：Windows Server 2016 Standard 上的基于内核的许可（64 位） 10.0（内部版本 14393：）

我们有多代应用程序连接到 SQL Server，其中一些我们知道 [他们的连接库] 不支持使用 MultiSubnetFailover=True 连接参数。美好的。

对于“说”他们能够使用 AG 侦听器的应用程序，一旦连接，有没有办法从 SQL 端验证这一点？不幸的是，我们的角色 (DBA) 并没有授予我们（我们也不希望）验证各种应用程序字符串以确保它们正确配置它的自由。这些老一代应用程序过去一直使用文字服务器名称，但我们正在尝试全部迁移到侦听器。

第一个帖子；请让我知道我的问题中可能缺少哪些信息。谢谢！

我可以在工作时间可读的辅助异步副本 (DR) 上运行Ola Hallengren 的 CheckDB 作业吗？目前异步副本不可读......

• 第一个问题是是否有可能。
• 其次，安全吗？

我有一个 Live 主服务器，我在工作时间/下班时间在辅助服务器上执行 CheckDB 。

我们有两个 SQL Server 2016 SP2 CU6 Enterprise 在物理硬件（32 核）上运行，其中一个 AG 包含 5 db。二级不可读。今天我们做了一个有计划的手动故障转移，所以我们可以在另一台服务器上做维护工作。我们在没有重负载的情况下进行了故障转移。

故障转移是通过 SSMS 的 GUI 执行的，没有出现错误。但是几分钟后，我们接到了很多用户无法登录的电话。我们第一次尝试进行故障排除是与 SSMS 建立连接，但这给出了我们无法连接的错误，我不记得确切的错误消息。

接下来我们在记事本中查看错误日志文件，它就像SQL Server引擎挂起一样。故障转移后没有新条目添加到日志中。

由于问题的紧迫性，我们重新启动了主服务器上的 SQL Server 服务，问题消失了。
我们本可以尝试建立 DAC 连接以查看问题所在，但目的是让服务器尽快恢复在线状态。

一切恢复正常后，我们开始分析日志文件。
在旧主服务器的错误日志中，我们发现了几个错误 35278。在故障转移时没有长时间运行的事务在运行。

接下来是 AlwaysON_health 事件文件，这里的条目在故障转移后刚刚停止。

接下来我们看了一下*_*_SQLDIAG_*_*.xel文件。在这里，我们很幸运。

我们注意到的第一件事是：

<queryProcessing maxWorkers="960" workersCreated="1064"
 workersIdle="23" tasksCompletedWithinInterval="19" pendingTasks="34"
 oldestPendingTaskWaitingTime="1316776"

由于某种原因，超过了最大工人数量，这可以解释为什么没有人可以连接。

这是待处理的任务：

<pendingTasks><br>
   <entryPoint name="Process Command" count="14" /><br>
   <entryPoint name="SNI New Connection" count="2" /><br>
   <entryPoint name="SNI Accept Done" count="3" /><br>
   <entryPoint moduleName="sqlmin.dll" imageBase="0x7ff827e80000" size="0x251e000" address="0x7ff8286622e0" count="6" /><br>
   <entryPoint moduleName="sqlmin.dll" imageBase="0x7ff827e80000" size="0x251e000" address="0x7ff8292b1190" count="2" /><br> …

我正在尝试在这里设置一个测试环境以了解更多信息并将其应用于我们的生产环境。

我已经使用 CLuster 管理器创建并安装了 Windows 集群。现在，我将在两台计算机上安装 SQL Server Enterprise 2014，然后使用可用性组创建 HA。故障转移将是手动的。它们将在同步数据传输中。

我的问题是，我是否可以正常安装“独立安装或添加...”SQL Server，或者我需要使用“新的SQL Server故障转移群集安装”。

我在互联网上找不到任何关于此的信息。

我将在将在集群中配置的两个节点上安装 sql server。

停止 SQL Server 服务时的行为：

• 可用性组失败（在 SECONDARY SQL SERVER 上解析并在集群管理上失败）。

• SQL Server 不与集群 ip 连接（我在软件内部使用固定的集群 ip 以便它在 SQL1 和 SQL2 上x.x.x.10连接。使用应该在x.x.x.9（SQL1）和x.x.x.8（SQL2）上连接我，因为windows failover cluster.

  • 我需要手动将 AG 移动到辅助（我在 SQL2 和 上连接right click > failover）。

• 要按原样返回所有内容，我需要SQL1 SERVICE手动启动、连接SQL1 SSMS和right click > failover手动。停止集群管理上的 NODE2 服务，使其再次将 SQL1 节点变为主节点。

停止主集群节点时的行为：

• 可用性组转到 SQL2/NODE 2（辅助现在是主要的）。

• 主 AG 未解决...

• SQL Server 与集群 ip 连接（我说的是 SSMS 。与 ipX.x.x.10连接x.x.x.8，在杀死节点x.x.x.9（ …