标签: availability-groups

Parallel redo is shutdown for database '' with worker pool size [2].

Parallel redo is started for database '' with worker pool size [2].

Starting up database ''

我在客户端 PC 上的 Windows 事件查看器（事件 ID 49930 或 17137）中经常看到这种情况。这是一台普通的 Windows PC，而不是服务器，带有 SQL Server 2017 Express Edition 和 SSMS 的默认实例。

什么是并行重做？

这是错误日志的输出：

2019-05-28 12:23:03.360 spid16s A self-generated certificate was successfully loaded for encryption.
2019-05-28 12:23:03.360 spid16s Server is listening on [ 'any' <ipv6> 1433].
2019-05-28 12:23:03.360 spid16s Server is listening on [ 'any' …

在玩 AG 设置时，我启动了 WSFC，并在一个名为 DevClusterOnline 的可用性组中配置了两个节点。两个节点（DEV-AWEB5 主节点，DEV-AWEB6 辅助节点）都运行 Windows Server 2008 R2。

如果我检查我的 AG 的健康状况，我会得到：

运行下面的查询将返回此结果集：

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

如果我断开 DEV-AWEB5，我无法连接到组侦听器 (DevListener)，但是我可以 ping 它并且它会响应我的 ping。副本 - DEV-AWEB6 进入 RESOLVING 状态，我的数据库无法访问。但是，我可以手动进入 Management Studio 并将故障转移设置为 DEV-AWEB6，然后我再次启动并运行，DevListener 将再次接受连接。

考虑到这些事实证实故障转移确实有效，我已经同步提交并配置了自动故障转移，我不知道如果我的设置出现故障怎么办。

当我断开 DEV-AWEB5 的连接时，我希望我的副本会保持连接，因此 DevListener 也会保持连接。我希望自动故障转移将允许我透明地连接到 AG 侦听器。从最终用户的角度来看，使用 Web 系统应该不会注意到其中一台数据库服务器出现故障。

我被困在这里，有人能告诉我我做错了什么吗？

今天早上，我被我们的一个数据库上的事务日志已满警报唤醒。这个服务器是一个alwayson 集群，也是一个事务复制订阅者。我检查了 log_reuse_wait_desc，它显示了 logbackup。4 天前有人不小心禁用了 logbackup 作业，我重新启用了日志备份作业，日志被清除了。由于是凌晨 4 点，我想我会在那天早上晚些时候去办公室并缩小日志，因为它已经增长到 400GB。

上午 10 点 - 我在办公室，我在缩小之前检查了日志使用情况，大约是 16%。我很惊讶并检查了 log_reuse_wait_desc，它显示了复制。我很困惑，因为这是一个复制订阅者。然后我们看到 db 为 CDC 启用，并认为这可能是原因，因此禁用 CDC，现在 log_reuse_wait_desc 显示 AVAILABILITY_REPLICA。

与此同时，日志使用量仍在稳步增长，目前为 17%。我检查了alwayson仪表板并检查了发送和重做队列，两者几乎为零。我不确定为什么日志重用显示为 AVAILABILITY_REPLICA 并且无法清除日志。

知道为什么会这样吗？

在 3 节点可用性组中，由于 Microsoft 文档中涵盖的原因，辅助副本通常会受到重做延迟的影响：

故障排除：主副本上的更改未反映在辅助副本上

根据我的经验，我最常看到的问题似乎是：

主要副本上长时间运行的事务会阻止在次要副本上读取更新。

和

辅助副本上的重做线程被长时间运行的只读查询阻止进行数据定义语言 (DDL) 更改。重做线程必须先解除阻塞，然后才能为读取工作负载提供进一步的更新。

我可以通过查看扩展事件会话“AlwayOn Health”来观察这一点：

当应用程序向辅助副本发出只读查询时，如果在主副本上运行大量记录的操作（如索引优化），同步滞后变得明显，并且我看到辅助副本上未提交的日志记录中有大量积压，如所述在上面的 MS 文档中。

我的问题是为什么我看到 CMEMTHREAD 在主副本上进行索引重组时在辅助副本上等待：

这是正常/预期的行为还是其他什么？

虽然辅助副本上有一些读取活动，但这些查询在运行时通常<1 秒，偶尔<10 秒查询。CPU 使用率在 5% 左右。

Output of @@VERSION: Microsoft SQL Server 2016 (SP1-CU10-GDR) (KB4293808) - 
13.0.4522.0 (X64)   Jul 17 2018 22:41:29   Copyright (c) Microsoft Corporation  
Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2012 R2 
Standard 6.3 <X64> (Build 9600: ) (Hypervisor) 

• 仅在辅助副本上观察到 CMEMTHREAD 等待
• 显示此等待（和滞后）的副本是主动查询的同步副本

更新：我刚刚发现在索引优化期间再次发生此 WAIT。我终止了索引作业，然后显然停止了同步延迟的增加，但是 CMEMTHREAD 等待继续并且重做似乎很慢。我还注意到偶尔 PARALLEL_REDO_FLOW_CONTROL 在重做线程上等待，所以我只是简单地执行，DBCC TRACEON (3459, -1)然后重做速度突然增加，积压开始非常快地清除。

您可以看到我在下午 …

我一直在测试 SQL Server 2012 中的可用性组功能，我发现当主服务器故障转移到辅助服务器时，大约有 15 秒的停机时间。在此期间执行的所有 SQL 查询都将失败，直到故障转移转换完成。

有什么方法可以将其降低到 0 秒并防止查询在故障转移转换期间失败？

换句话说，有没有办法让在失败期间运行的任何查询被重定向到主服务器而不是失败......并且有没有办法让新的数据库连接立即连接到辅助服务器而不是失败在故障转移过渡期间连接？

我目前在可用性组中设置了 2 个服务器。

我每 15 分钟在 SQL Server 错误日志中收到此错误消息。我已经在这台服务器上设置了 AOAG。为该实例上的 Blackberry 相关数据库和 MSDB 数据库启用了数据库选项“Service Broker - Broker Enabled”。黑莓支持提到他们不需要启用此功能。我有其他 AOAG 实例，他们没有收到此错误。

请分享您在这方面的智慧。我还没有使用过服务代理，也没有在我的搜索中找到关于堆栈交换的类似帖子。

谢谢

我们有一个 Always On 可用性组，其中包含一个主要和一个已启用读取的次要。我们有一个实施团队的用户，他使用数据库来检查他们打算放入数据库的数据的正确性。

用户只有从数据库读取的权限，但是当他们通过 AG 侦听器连接（通过 SSMS）时，他们总是连接到活动节点。

我试图让他们直接访问只读实例，但他们坚持自己的方式，一两天后他们又回到了活动节点上。

SQL Server 有没有办法说这个用户总是打算只读并将他们重定向到那里？

注意：我已经尝试在附加连接参数中设置“ApplicationIntent = ReadOnly”，但这似乎没有重定向到辅助节点，并且不是理想的解决方案，因为他们不可避免地会忘记为新的初学者设置它。

SQL Server 2012 Enterprise，可用性组 1 主要，1 可读次要同步提交。

我不打算让用户连接到链接服务器，或通过任何其他服务器。用户通过 SSMS（没有其他应用程序）直接连接到数据库，我希望 AG 侦听器（或那里的其他东西）能够将该用户引导到一个可用的辅助节点（因为它只有读取访问权限）访问主节点是没有意义的）而用户无需做任何事情，因为他们在机器周围移动并且会忘记添加应用程序意图。此外，我发现将其添加到其他连接参数并不总是将您定向到辅助节点。

我正在查看 AlwaysOn 可用性组。我越看它就越发现可用性侦听器组是单点故障。侦听器究竟在哪里运行？一个单独的服务器，主SQL服务器，所有这些？

假设我在我的第二个数据中心有一个完整的应用程序堆栈。如何配置侦听器，以便它们在两个站点上运行并且应用程序将指向它们自己的本地副本？

我确定我在这里遗漏了一些东西，但我不知道是什么。

我正在审查我们公司的 DR 程序，当我在网上查找 Always On 群集丢失仲裁的解决方案时，进行比较。在找到关于集群与事务复制与可用性组主题的第一篇 SE 帖子之前，我在谷歌搜索结果中翻了三页，该帖子仅略微涉及丢失法定人数的主题。

虽然每个人都同意失去法定人数是糟糕的，并且有一些降低潜力的建议，但它仍然可能发生。我正在寻找一个经过同行评审的良好答案，以了解从 Always On 集群仲裁丢失中恢复的最佳途径。

我有一个 4 节点 AG 设置，如下所示：

所有节点的VM硬件配置：

• Microsoft SQL Server 2017 企业版 (RTM-CU14) (KB4484710)
• 16 个 vCPU
• 356 GB RAM（这个故事很长……）
• 最大并行度：1（根据应用程序供应商的要求）
• 并行性的成本阈值：50
• 最大服务器内存 (MB)：338944 (331 GB)

AG配置：

• 节点 1：主节点或同步提交非可读辅助节点，配置为自动故障转移
• 节点 2：主节点或同步提交非可读辅助节点，配置为自动故障转移
• 节点 3：具有异步提交的可读辅助集，配置为手动故障转移
• 节点 4：具有异步提交的可读辅助集，配置为手动故障转移

有问题的查询：

这个查询没有什么特别疯狂的地方，它提供了应用程序内各个队列中未完成工作项的摘要。您可以从下面的执行计划链接之一中查看代码。

主节点上的执行行为：

在 Primary 节点上执行时，执行时间一般在 1 秒左右。这是执行计划，以下是从主节点的 STATISTICS IO 和 STATISTICS TIME 捕获的统计信息：

(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table …