SQL Server 2017 CU1 是否会破坏无集群可用性组？

Question

背景：

我的部门正在从带有镜像的 SQL Server 2008R2 升级到带有无集群可用性组的 SQL Server 2017。直到最近，测试才发现没有问题或危险信号。然后我们安装了 CU1，遇到了问题，卸载了 CU1，问题就消失了。操作系统是带有最新补丁的 server 2016。

CU1 后观察到的行为：

使用 SSMS 或 tsql，我们可以创建一个 2 副本无集群同步可用性组，并向其中添加一个数据库。该组可以多次故障转移而不会出现问题。啊，但是添加第二个数据库，故障转移会出现问题。其中一个数据库总是会处于不同步状态。再多的摆弄也无法让它复活。如果我删除并重新创建整个内容，则可能是其他数据库未同步。记录器中的相关错误消息是“由于异常 35222，无法更新副本状态”。这似乎是一条与集群相关的消息，但由于我们是无集群的，我感到很困惑。在我们卸载两个副本上的 CU1 后，我能够创建 AG 并添加 22 个数据库（包括两个原始数据库）。故障转移没有问题。附带说明一下，自动播种并不总是适用于多个数据库。该操作将失败并显示“种子检查消息超时”。从 AG 中删除这些数据库并一次添加一个是成功的。

我的问题是：

在 CU1 之后，是否还有其他人遇到过无集群 AG 的问题？如果是这样，你在我没有成功的地方成功了吗？

评论/意见：

我认为 CU 将在与 SP 相同的级别进行测试。虽然我知道无论测试多么彻底，错误都会出现，但在第一个测试中发生这种情况令人不安。这将导致我们在部署之前对每个 CU 进行真正的压力测试，这意味着我们不会在它们出现时部署它们。我们只会在我们认为有必要时部署它们。我们是一个没有专门的 dba 的小型组织，需要对所采取的行动有所选择。

Answer 1

我的部门正在从带有镜像的 SQL Server 2008R2 升级到带有无集群可用性组的 SQL Server 2017。

所以您正在升级版本但正在删除高可用性和灾难恢复？无集群 AG 被称为“读取规模”AG，不提供高可用性，您可以在灾难恢复部分争论...

该组可以多次故障转移而不会出现问题。啊，但是添加第二个数据库，故障转移会出现问题。其中一个数据库总是会处于不同步状态。再多的摆弄也无法让它复活。

当仅配置副本（在 CU1 中出现）未与用于故障转移的 Read-Scale AG 一起使用时，我已经看到了这一点。Read-Scale 不是为了故障转移和所有爵士乐，而是为了在密集读取情况下水平扩展读取副本（或者作为跨 Windows/Linux 复制以进行迁移的一种方式）。我必须重申，“无集群”AG 不是为 HADR 设计的。如果这是您的用例的一部分，请使用 WSFC 或 Pacemaker (Linux)。有关仅配置副本的信息。

记录器中的相关错误消息是“由于异常 35222，无法更新副本状态”。这似乎是一条与集群相关的消息，但由于我们是无集群的，我感到很困惑。

在此之前应该有一个错误，这就是您要查看的实际错误。这与聚类没有任何关系，也不是聚类错误，而是副本错误。

在我们卸载两个副本上的 CU1 后，我能够创建 AG 并添加 22 个数据库（包括两个原始数据库）。故障转移没有问题

这可以追溯到用于添加到读取规模副本的仅预配置副本。同样，很惊讶您没有遇到一些不同的问题，因为 Read-Scale 不是为 HADR 设计的。

附带说明一下，自动播种并不总是适用于多个数据库。该操作将失败并显示“种子检查消息超时”。

似乎无关，但你永远不知道 - 可能是正在发生的事情的副作用。在这一点上无法说。

我认为 CU 将在与 SP 相同的级别进行测试。

你是对的。考虑到更新的模型，CU 之间的行为变化（很像也涉及到 SP）可以而且确实发生（即使在 SP + CU 时代也发生了这种情况）。我很想知道配置副本是否解决了您的问题，因为它是专门添加到 CU1 中以确保元数据安全，因为副本的元数据问题可能并且确实发生了，因为 Read-Scale再次不是为 HADR 制作的。