Bla*_*las 4 sql-server availability-groups sql-server-2016 sql-server-2017 distributed-availability-groups
我有一个由 2 个 SQLServer 2016 实例（WSFC 中的 2 个 Windows 2016 服务器）组成的旧可用性组 我还有 2 个新的 SQLServer 2017 实例（2 个 Windows Server 2016），我最初想加入 2016 AG。
这是一个 0 停机迁移场景，一旦数据库与 2017 年的数据库对齐，2016 年的服务器应该被解雇。
令我非常失望的是，我发现无法将 2017 实例加入现有的 2016 AG，但我无法承担停止生产、获取和恢复备份、等待数据库同步、更改名称（以及可能的新 AG 的 ip) 与原始 AG 匹配，除非作为最后一个资源......
然后我遇到了名为“Distributed AG Group”的 2016 年新服务，我开始考虑将它用于我的迁移场景......基本上是这样的：
是否可行？我可以在分布式 AG 中混合 2016 和 2017 AG 吗？或者有（显然！）我遗漏的东西，并且有更简单或更正确的方法来制作它？
是否可行？我可以在分布式 AG 中混合 2016 和 2017 AG 吗？
我已经从Allan Hirt SQL Server MVP 和 HA/DR Guru 确认这确实是可能的并且得到支持。所以请继续，可能会出现混淆，因为在 BOL 中提到了两个不同的东西。我将突出两者
引自分布式可用性组文档
分布式可用性组跨越多个可用性组，每个可用性组都位于其自己的底层 WSFC 群集上，并且分布式可用性组是仅限 SQL Server 的构造。这意味着容纳各个可用性组的 WSFC 群集可以具有不同的 Windows Server 主要版本。SQL Server 的主要版本必须相同
因此，虽然您可以在 DAG 中有不同的 Windows 服务器版本，但在 DAG 中不能有不同的 SQL Server 版本。从这里开始，版本似乎应该相同，但是如果您再次查看升级可用性组实例，它会说
若要使用 AG 迁移到新版本的 SQL Server 实例，唯一受支持的方法是分布式 AG，它位于 SQL Server 2016 企业版或更高版本中。
现在你应该相信这个而不是前一个。
或者有（显然！）我遗漏的东西，并且有更简单或更正确的方法来制作它？
除了分布式 AG，我会在这里考虑 2 种方法
我相信事务日志运输应该在这里有所帮助。
创建安装了 SQL Server 2017 的新 WSFC--无停机时间
现在不要创建 AG
Logship 数据库从 SQL Server 2016 到 SQL Server 2017。--无停机时间
在“转换”期间停止日志传送并使 SQL Server 2017 上的数据库联机。--小停机时间
现在将应用程序指向这个新数据库。
继续并在新的 SQL Server 2017 上配置 AG。
我知道如果您有大型数据库，配置日志传送会带来一些痛苦，但这是我所看到的最好的。
进行可用性组的滚动升级。升级可用性组实例