问题标签 [availability-group]

我们为客户配置了一个具有同步提交模式和两个集群的可用性组。一个集群是主集群并且是可写和可读的。另一个集群是辅助集群并且是只读的。我们使用辅助集群进行只读操作。此外，我们在 asp.net 门户上使用此集群来读取数据库，并使用主集群来写入数据库。通过测试门户和 AG 的功能，我们发现了一个问题。通过更改门户中某些数据库表中的数据并单击“保存”，站点的刷新会显示旧数据，直到我们再次刷新站点。第一个问题是同步提交模式到底是什么意思？在主节点上提交数据后，我可以从辅助节点读取数据吗？

我在数据库上写了一个表和脚本来测试读/写功能。

创建一个表进行测试：

在主集群上插入 30000 个数据行的第一个脚本：

第二个脚本，用于在循环中每 2 毫秒读取一次辅助集群：

第一步，我运行第二个脚本并连接到辅助集群以跟踪我可以看到辅助集群上的数据的时间点。在下一步中，我运行第一个脚本将数据插入到主集群上的表中。最后，当插入的数据在辅助设备上可读时，我检查了主设备上提交的日期时间和辅助设备上的日期时间。

结果：

在主集群上提交后大约一秒钟后，辅助节点上的数据可以读取。这就解释了门户网站上的保存刷新问题。我们将数据保存在主节点上，并且刷新比提交后的延迟更快。

任何机构都可以解释这种现象吗？对于 asp.net 门户的这种情况是正确的，还是我们应该只将门户用于主集群？

对不起，我的英语不好。

最好的祝福，

亚历克斯

我们正在尝试在高可用性集群环境中为数据库设置复制，其中主数据库服务器的中断将自动故障转移到辅助服务器。

此外，我们使用的是基于工作组的环境而不是基于域的环境，因为在这种情况下域控制器将是多余的。

配置：操作系统：WinServer 2019 SqlServer：2017 复制：合并，基于推送

我们无法使用集群使用的名称（即解析为集群 IP 地址的名称）设置发布者。该设置只允许数据库服务器的名称，它解析为主数据库服务器的 IP。

是否可以在基于工作组的可用性组环境中设置 Sql Server 复制？

我有一个配置有 2 个节点的 SQL AlwaysOn 可用性组。AG 在这 2 个节点上工作没有任何问题，我可以对它们中的任何一个进行故障转移（这些服务器位于同一网络上）。

最近，我在 AG 中添加了另一台服务器，但这台是 Azure VM。我成功地将它添加到 AG，播种模式为“自动”，并配置为“可读辅助”。所有数据库都在 Azure VM 上创建，但它们仍处于“同步/恢复中”模式，我已重新启动服务器，删除数据库并再次添加它，但所有数据库始终保持在该模式下。在本地辅助副本上，所有数据库都处于“同步”模式，我可以访问所有数据库进行只读操作。

如何使这些数据库脱离“恢复中”状态？

问候。

在 MABS 文档 ( https://docs.microsoft.com/en-us/azure/backup/backup-azure-microsoft-azure-backup ) 中写到我们不能在作为集群节点的计算机上安装 MABS所以我只是想确保我需要额外的机器。

我正在尝试使用非常简单的数据库（只是一个用于概念证明的单表测试数据库）在 SQL Server 2017 和 SQL Server 2019 实例之间创建一个 Always On AG。

除了辅助副本卡在 SSMS 中的“同步/恢复中”状态外，一切似乎都运行良好。

即使我将其标记为允许所有连接，我也无法连接到副本。

如果我对数据库进行更改并故障转移到副本，那么更改就在那里。一切看起来都不错，但我无法使用普通连接字符串或只读意图连接到副本。

我看到了以下主题，并看到解决方案是在两个副本上使用相同版本的 SQL Server。理想情况下，我希望在我的主服务器上使用 2017，在辅助服务器上使用 2019，因为这是我们当前的生产环境。如果我能够组建 AG 组，最终将允许我在不停机的情况下将 SQL Server 2017 实例升级到 SQL Server 2019。

将服务器添加到 SQL Avaylability Group 后，数据库卡在“同步/恢复中”模式

SSMS 状态

AG集团状态查询

我有两个在 Linux 上运行的 SQL Server 2019 实例。这两个实例都包含一个使用 AlwaysOn 可用性组同步的数据库。数据库中的数据是同步的，但问题是 SQL 代理作业不是数据库本身的一部分。

因此，当我在主副本上创建 SQL Server 代理作业时，此配置不会复制到辅助副本。所以，在创造了每个工作之后，我总是必须去中学并在那里创造工作。而且我必须一直跟踪我所做的所有更改。

使用可用性组时，是否有一种内置方法可以在 Linux 上自动执行 SQL Server 作业的这种跨副本同步？跨 AG 副本的作业同步似乎应该已经被 SQL Server/SQL Server 代理工具原生支持，但我没有从 Microsoft 找到任何东西，只有一个名为DBA Tools的第三方工具，我可以使用它来编写自己的自动化脚本在 PowerShell 中。

我正在运行带有异步复制的 SQL Server 2019 Always ON 可用性组。

我使用了一个名为IDERA SQL Check的免费工具，我发现了SPID 69哪个程序名称是Replication Distribution Agent. 它总是在那里，像一只无聊的猫一样盯着我看。

这SPID 69指向一个镜像的特定数据库，我用这个查询对其进行了调查：

这给了我这样的回应：

• session_id = 69
• 文本 = 开始翻译
• login_time = 2020-09-08 18:40:57.153
• program_name = 复制分发代理
• 状态 = 睡觉
• cpu_time = 1362772
• memory_usage = 4
• total_scheduled_time = 1689634
• total_elapsed_time = 22354857
• last_request_start_time = 2020-09-28 16:28:39.433
• 读取 = 18607577
• 写入 = 5166597
• 逻辑读取 = 112256365

现在，在互联网上，我发现当你看到Replication Distribution Agent一切都很好时，那个代理应该会去，应该没有问题。但为什么：

1. 文字说begin tran，仅此而已？
2. IDERA SQL Check 将其标记为connection idling transaction?
3. 状态是sleeping？
4. 我担心这CPU time, reads and writes基本上是在告诉我这个过程正在用永无止境的 I/O 煎驱动器，对吗？

事务日志不断增长，数据库退出可用性组后无法收缩。当我检查 log_reuse_wait_desc 时，它显示“可用性副本”。但数据库已从 AG 中删除。我很困惑，现在不知道该怎么办，我在 SQL 2019 CU4 上尝试了通常的 - 日志备份 -> 收缩更改为简单，返回不起作用。

我们设置了一个 SQL 可用性组，并在 AlwaysOn 数据库的 SQL 可用性组的主节点上打开了更改跟踪。在触发自动故障转移并将辅助节点设为主节点之前，更改跟踪工作得非常好。一旦故障转移指向新的主节点，更改跟踪就会失败。

有没有一种方法可以配置为在 SQL 可用性组中的节点之间共享更改跟踪元数据？

所以我们有一个 SQL 2016 集群 AG 组。这是我们知道并尝试过的。

• 我们的 Windows 故障转移集群和 SQL 可用性组是“SQL-Clus”并指向“节点 1”和“节点 2”。
• 通过 SSMS，windows 认证用户是一个 SA，在“节点 1”和“节点 2”的登录中单独分配，并且可以毫无问题地登录到各个节点。
• 当这个用户尝试连接到 SSMS 中的“SQL-Clus”时，他们得到“错误：18452，严重性：14，状态：1。登录失败。登录来自不受信任的域，不能用于 Windows 身份验证。”
• 其他单独分配的 SA 或其他 AD 用户在连接到 SSMS 中的集群名称时没有任何问题。
• 我们已尝试从两个节点中删除用户并将其重新添加，但错误仍然存​​在。
• 我们注意到该用户也无法通过 SSMS 连接到 AG 组的任何集群名称。

请记住，这只是一个用户，因此很可能是他们的个人域帐户引起了这种情况。其他都很好。再次，该用户可以很好地连接到“节点 1”和“节点 2”。