标签: availability-groups

我在 AlwaysOn 可用性组中设置了 2 个 SQL Server。

我还设置了针对数据库运行的作业。在故障转移期间，我如何确保作业将继续在辅助服务器上运行？我是否需要在两台机器上安装作业和 SSIS 包并在辅助机器上手动禁用它们...然后在故障转移的情况下手动启用它们？或者是否有内置功能来处理这个问题？

首先我不得不说这个问题来自软件工程师的角度。不幸的是，我们没有 DBA，所以我们需要管理我们自己的数据库。

我们安装了 SQL Server 2012 Enterprise 来运行一个应该 24/7 可用的数据库。数据库大约 150 GB，一些表包含数十亿行。多个服务每分钟访问数据库数千次，以插入实时测量数据。所以当数据库宕机半小时，测量数据丢失半小时，这是我们承受不起的……

在这种情况下，我们有两个主要问题：

1. 我们何时以及如何安装 Microsoft 更新？
2. 我们如何应用架构更改？

我认为 Windows 更新不需要进一步解释。当新需求出现或现有需求发生变化时，我们有时需要进行一些架构更改。例如添加一些额外的列、更改数据类型、调整 varchar 字段的大小等。其中一些更改需要很长时间才能运行，甚至超时，因为数据库始终处于高负载下。

我们正在考虑安装一个额外的实例并启用 AlwaysOn，以完成以下操作：

1. 对于 Windows 更新，关闭一台服务器，安装 Windows 更新，重新启动，然后更新第二个实例。
2. 对于架构更改，关闭一台服务器，应用架构更改，将其恢复，然后将相同的更改应用于第二个实例。

这两件事可以通过 SQL Server AlwaysOn 来完成，这是一种常见的方法吗？数据甚至会在之后同步吗？还是我完全在考虑错误的方向，是否有更好的解决方案？

我们在 Windows Server 2012 多子网故障转移群集上使用 SQL Server 2016 可用性组 (AG) 来实现 HA/DR。我们的纽约数据中心（10.7.xx 子网）中有两个节点，我们的科罗拉多数据中心（10.8.xx 子网）中有一个节点。科罗拉多服务器主要用于灾难恢复或纽约离线的扩展维护，因此我们目前将 CO-SQL01 节点的 Quorum NodeWeight/Votes 设置为零，以防止它在出现任何问题时自动获得集群或 AG 的所有权.

我的问题是：我们是否应该更改故障转移群集管理器中的默认设置，特别是 AG 角色的首选所有者和 AG 侦听器 IP 资源的可能所有者？使用的默认值似乎与我们在纽约使用两个节点并仅使用 CO 节点进行灾难恢复的高可用性目标相冲突。

以下是我们多子网 AG 的首选所有者的默认设置：

我们是否应该在 NY-SQL02 旁边添加一个检查并将其移动到 CO-SQL01 之上，以便它成为首选？其他角色呢，我们可以设置核心集群资源的首选所有者吗（比如集群名称）？

以下是 SQL-StackOverflow_AG IP 资源的默认设置：

我们是否应该删除与该 IP 地址位于不同子网中的服务器旁边的复选标记？

这个问题是在最近的办公时间提出的，但是当我们的集群出现问题时，我们可能会帮助防止停机。我们最近在更换 CO-SQL01 服务器硬件时发生了 5 分钟的中断，它被添加回故障转移集群（但不是 AG）而没有删除它的投票。CO-SQL01 服务器随后发生了严重崩溃（我们认为这是重负载下的 NVMe/PCIe 驱动程序错误）并设法将 AG 与它一起删除（我们认为 CO-SQL01 在它出现时获得了核心集群资源的所有权重新上线）。

老实说，我们在使用多子网故障转移群集可用性组时遇到了许多意外问题，似乎默认首选角色所有者和可能的资源所有者可能不正确，或者至少不是我们方案的最佳选择。我们目前正在考虑使用SQL Server 2016 中新的分布式可用性组功能将我们的多子网 AG 拆分为两个单个子网 AG（每个数据中心一个），以防止将来出现这些问题。我们还认为这将使我们能够以最少的停机时间升级集群操作系统。

在评估将托管 AG 的 SQL Server 2012 实例滚动升级到 SQL Server 2016 的可能性时，我们遇到了一个不太合理的奇怪问题。一种更简单的演示方法如下：

假设您想将数据库添加到 AG（正在使用 2012 实例）。SSMS 2012 或 SSMS 2014 向导显示不出意外：

然而，SSMS 2016 讲述了完全不同的故事：

对于已经是 AG 一部分的数据库，它说“不满足先决条件”而不是“已经是……”，对于那些不在 AG 中的数据库，它说“需要密码”，并附有以下解释：

“此数据库由数据库主密钥加密，您需要在将其添加到可用性组时提供有效密码。”

此消息的问题在于没有任何数据库使用任何加密。

如果您从 2016 实例上的 2012 AG 备份还原数据库并尝试使用 SSMS 2016 向导将其添加到 2016 AG，则会出现同样的问题。

我正在根据https://docs.microsoft.com/en-us/sql/linux/sql-server-linux为 Linux 配置 Always-on for SQL Server 2017 RC1（14.0.80.90，日期为 2017-7-18）-availability-group-configure-ha。此安装使用 docker 映像，全部位于同一物理主机上。所有步骤都在工作，直到我到达步骤：

CREATE AVAILABILITY GROUP [ag1]
    WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
    FOR REPLICA ON
        N'always-onA' 
         WITH (
            ENDPOINT_URL = N'tcp://always-onA:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
        N'always-onB' 
         WITH ( 
            ENDPOINT_URL = N'tcp://always-onB:5022', 
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
        N'always-onC'
        WITH( 
           ENDPOINT_URL = N'tcp://always-onC:5022', 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           FAILOVER_MODE = EXTERNAL,
           SEEDING_MODE = AUTOMATIC
           );

我收到错误消息：

Msg 35237, …

我最近一直在使用 SMO 来检查一些属性，并且在尝试收集有关 SQL Server 2016 中的读取路由顺序的信息时遇到了一个问题。

在早期版本中，路由列表非常简单，列表将按顺序处理，但在 2016 年，他们引入了循环算法，允许您让多个辅助副本接受读取流量。

虽然此数据可通过 T-SQL 访问，但 SMO 似乎并未更新以反映这一点，这意味着您无法准确获取或设置配置，因为它仍然是一个简单的字符串集合。

是否有一些我遗漏的属性可以让我获得 SQL Server 2016 的准确数据？（下面的 C# 示例 SMO 调用）

它只是似乎无法访问的循环信息，它列出了读取路由列表中的所有副本，它似乎没有区分可能存在的各种副本组。

连接错误报告。 连接已死...

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.SqlServer.Management.Smo;
using Microsoft.SqlServer.Management.Common;

namespace SmoTesting
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Enter the servername");
            string connectServer = Console.ReadLine();
            Console.WriteLine("Enter the AG name");
            string agName = Console.ReadLine();

            Server srv = new Server();

            try
            {
                srv = new Server(connectServer);
                srv.ConnectionContext.StatementTimeout = …

我们在 SQL Server 2014 SP2 CU5（3 个节点）中有一个 AOAG。有一个读取提交的快照隔离级别为ON的数据库。我们有一个压缩的大表。我们在这个表上的一些更大的查询是在辅助中执行的。

然后在主节点上有一个夜间作业来重新组织几个表上的索引。当它遇到上述表的聚集索引时，我们会收到以下错误：

访问数据库 'yyyy' 中的表 'xxxx' 中的版本化行时事务中止。未找到请求的版本化行，因为尝试创建版本的操作不允许可读的辅助访问。

在某些时候，大查询正在执行带有提示的读取READUNCOMMITTED。我认为这是这个错误的原因，所以我删除了它们。但是错误仍然存​​在。

有任何想法吗？

当前设置：

• 02 次要处于同步模式
• 03 次要异步模式

表详细信息

• 行数：122.567.668
• 总空间MB：18.460
• 已用空间MB：18.238

定义：

CREATE TABLE [dbo].[big_table](
[ID] [int] NOT NULL IDENTITY(1, 1),
1 [int] NULL,
2 [datetime] NULL,
3 [int] NULL,
4 [int] NULL CONSTRAINT [DF_ccc_bUnits] DEFAULT ((0)),
5 [money] NULL,
6 [money] NULL,
7 [int] NULL,
8 [int] NULL CONSTRAINT [DF_ccc_MinDays] DEFAULT ((0)),
9 [int] NULL,
10 [int] NULL,
11 …

执行任何 DMV 还是有另一种方法来公开重做队列中正在同步到辅助副本的数据类型？（例如，它是表数据和哪个表，还是索引更改和哪些索引等？）

我正在尝试在我的 SQL 服务器上激活高可用性并收到以下消息：

SQL 服务器版本：Microsoft SQL Server 2017 (RTM) - 14.0.1000.169 (X64) 2017 年 8 月 22 日 17:04:49 版权所有 (C) 2017 Microsoft Corporation Express Edition（64 位），Windows Server 2012 R2 Datacenter 6.3（Build 9600） :)（管理程序）

操作系统：windows server 2012。

感谢任何帮助。

我有两台服务器 A 和 B。两者都位于 Always On 组中。B 服务器配置为只读请求。到目前为止，这工作得很好，但最近查询服务时出现了问题。

该服务首先对表（可能在 A 服务器上）进行更新，然后在 B 服务器上进行只读选择。开发商表示，这是两笔独立的交易。

不幸的是，选择不会返回之前进行更新的值。仅在大约 1 到 1.5 秒后才会出现正确的值。我们以前从未能够观察到这种行为。

服务器设置为同步提交。所有数据库都是同步的，没有数据丢失。只读路由已经过测试并且有效。可读辅助设置为“是”。

我作为MSSQL数据库的DBA工作了大约1.5年，我不太明白AG中的两个节点A和B如何通信，但我假设两个节点会同时接收数据使用“同步提交”，对吗？

造成 1 到 1.5 秒时间差的原因是什么？

服务器是带有 CU12 的 SQL 2019 Enterprise - 在带有 Windows Server 2016 Standard 的一些功能强大的物理机上运行。