标签: availability-groups

我有一个 2 节点 FCI 和一个非 FCI 节点上的独立 SQL Server 安装。我一直在自动化 FCI、AG 和 DB 副本的配置/安装，到目前为止，它在我的所有测试中都运行良好。

今天执行时出现以下错误：

USE [master]
GO
CREATE AVAILABILITY GROUP [AGName]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR 
REPLICA ON N'Node3\ReadOnly' WITH (ENDPOINT_URL = N'TCP://Node3-blah.blah.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, SESSION_TIMEOUT = 10, BACKUP_PRIORITY = 50, PRIMARY_ROLE(ALLOW_CONNECTIONS = ALL), SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
    N'Primary/Primary' WITH (ENDPOINT_URL = N'TCP://primary.blah.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, SESSION_TIMEOUT = 10, BACKUP_PRIORITY = 50, PRIMARY_ROLE(ALLOW_CONNECTIONS = ALL), SECONDARY_ROLE(ALLOW_CONNECTIONS = NO));
GO

错误：

消息 19405，级别 16，状态 …

我们有一个独特的情况，我们希望允许用户使用 SSMS 查询数据库的可读辅助副本以进行临时报告，但不允许他们从主副本中读取数据。我们设置了只读路由来完成此任务。这也是 SQL 2016 上的全部。

我最初的想法是在主副本和辅助副本上创建登录名，并授予对相关数据库的读取访问权限。然后我们将拒绝连接或禁用当前主副本上的登录。在 SSMS 中，用户可以使用 ApplicationIntent=ReadOnly 连接到侦听器，并路由到辅助副本，而无需接触主副本。

我们将使用基本逻辑在主副本服务器和辅助副本服务器上设置一个简单的作业：如果当前服务器=主服务器，则禁用登录；如果当前服务器 = 辅助服务器，则启用登录。

问题是，当在主服务器上禁用登录时，以只读意图连接到侦听器时，我会遇到登录失败。当我在主副本上重新启用登录时，它工作得很好，并且连接已正确路由到可读的辅助副本。

我在主服务器上设置了跟踪，果然，我可以看到登录连接并在主副本上的 master 和 msdb 中运行一些系统类型查询 - 即使我在 SSMS 中使用 ApplicationIntent=ReadOnly 进行连接。我不确定这是否是 SSMS 在幕后执行的操作，或者是否是登录通过只读路由过程的默认行为。

以下是我在主数据库上使用快速分析器跟踪捕获的查询：

--msdb query

    select 
        case 
            when object_id('dbo.sysdac_instances') is not null then 1             
        else
            0 
        end

--master query

SELECT
dtb.name AS [Name],
dtb.database_id AS [ID],
CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible]
FROM
master.sys.databases AS dtb
ORDER BY
[Name] ASC

以前有人处理过这种情况吗？看来我们基本上需要允许主副本上的登录连接权限，同时拒绝其对主副本上 AG 中的数据库的读取访问权限，但授予该登录权限以读取可读辅助副本上的数据库。

另一种选择是创建一个直接指向辅助副本的 DNS 条目，但我们不能保证该副本始终是辅助副本，因为可能会发生故障转移。

我有一个现有的 SQL Server 实例，其中包含三个数据库和少量数据。

我现在被要求创建一个 Always On 可用性组。现有服务器需要重新调整驱动器的大小，并且只有 3 个 vCPU。

所以，如果你有一个选择，什么是最简单/最安全的？启动新服务器，设置 Always On，然后从现有服务器迁移数据？

或者我应该保留现有的服务器和实例并将 Always On 可用性组添加到现有的 SQL Server 实例？

SQL14 是主服务器，SQL16 是辅助副本，它们使用同步提交可用性模式进行设置：

截至昨天，数据似乎停止从主服务器同步到副本服务器。今天早上我们暂停了可用性数据库，然后恢复了它。当我现在看到新数据通过时，这似乎再次启动了同步，但仪表板中的重做队列大小和估计恢复时间仍然很大并且还在继续增长。

我可以检查/做些什么来解决这个问题？

附加信息：服务器版本：SQL Server 2016 Enterprise - SP1（在主服务器和辅助服务器上）

此外，我们有一些长时间运行的索引重新组织/重新构建作业在早上早些时候在主服务器上失败。（那是大约 4 小时前的事，但现在这是否仍然可能是导致此问题的潜在因素？）

我注意到辅助服务器上的以下服务器日志（从最旧到最新）：

不知道里面有没有什么线索？

辅助节点上的 DBCC OPENTRAN 返回以下内容：

扩展事件会话以跟踪辅助节点上的等待：

我们在高可用性组中有一些服务器，需要为服务器上发生的任何故障转移配置电子邮件通知。

这是一个奇怪的场景。事务日志已满。它等待AG。AG一切都好。无延迟，最后提交/硬化时间在所有节点上几乎都是实时的。预计恢复时间为零。我也从主节点和辅助节点检查了这一点（以防仪表板未更新）。此页面仅列出了此错误的两个原因：传递延迟和重做延迟。没有任何内容适用于我的系统。如何进一步解决这个问题？

编辑 1。我们对环境所做的唯一更改是添加了两个 SQL Server 2019 节点以准备迁移。但它不应该出现这样的问题。

编辑2。我发现的唯一解决方法是将数据库重新添加到AG。

SQL Server 可用性组备份首选项。

我们的 AG 有 3 个节点。

我想在主数据库上进行完整备份和差异备份，在辅助数据库上进行日志备份。

当我配置“任何副本”时，所有副本的备份优先级均为 50，日志备份不在辅助副本上运行。

如果我确实喜欢辅助完整备份，则不会在主数据库上运行。

如何配置为仅在主数据库上进行完整/差异备份并仅在辅助数据库上进行日志备份？

我们希望将备份卸载到辅助副本的原因是为了提高主副本在高峰时段的性能。

我们当前的设置每 3 天进行一次完整处理，并在每天下班后进行比较，我们\xe2\x80\x99ve 每 15 分钟运行一次日志备份。它通过具有自定义 SP 的 SQL 代理作业\xe2\x80\x99s。

在不需要 WSFC 集群的 SQL AG（读取扩展）异步模式下，假设以下场景：

1. 主节点将数据写入其事务日志并将该日志记录发送到辅助节点
2. 假设在上述日志记录到达辅助节点之前辅助节点已断电

当辅助数据库启动时，它如何将其数据库与主数据库同步？这是自动还是手动过程？

我在分布式 AG 设置中观察到 log_send_rate 较低。我知道 AG 使用日志流，所以我认为它不应该与数据有任何关系，但我想知道这是否与它正在传输的数据有关，而不仅仅是操作系统资源（网络、I/O）？

供考虑的基本指标：

• SQL Server 2019-CU16
• 源 RAM 1.5 TB，48 个 CPU <> 目标 RAM 128 GB，48 个 CPU - 内存差异在这里起作用吗？
• 两台服务器位于同一 DC，ping 延迟<1ms。目标服务器是虚拟机。
• ROBOCOPY 测试显示文件传输速率约为 100 MB/s
• 当高事务日志生成活动（例如索引维护或创建）发送到其他副本时 - 它以最大 20 MB/s 的速率传输（这不是预期的）。这是 log_send_queue 堆积起来的时候。
• 另一端的 REDO 速率良好，没有 REDO 队列堆积在那里。

在源 AG 上，我没有看到“发送到传输的字节数/秒”计数器的任何内容，因此我无法确定这是否是瓶颈。

如果我遗漏了任何我应该包含的内容，请提出建议。

我创建了一个包含的可用性组，但我不知道为什么作业在节点之间不同步。可能是什么问题呢？它不应该自动完成吗？

为了响应这个答案，我执行了以下操作：

我已连接到我们现在用作主服务器 (xxxxx) 的服务器，并且我在那里创建了一个测试作业。

数据库的同步工作正常，但不适用于登录和作业。