我正在测试情况下工作，并且已经成功创建了一个具有自动播种功能的分布式可用性组。我无法弄清楚如何将另一个数据库添加到分布式 AG。我成功地将新数据库添加到主 AG，但是 alter availability group 语句在分布式 AG 上似乎不起作用。我收到以下错误：
消息 15151，级别 16，状态 1，第 28 行
无法更改可用性组“xxxx”，因为它不存在或您没有权限
尝试修改我的组登录权限会产生相同的消息，但该组处于 sysadmin 角色下。确定有创建分布式AG后添加数据库的方法吗？
我们计划从 SQL Server 2008 R2 升级到 SQL Server 2014，目的是使用可用性组。
其中一个辅助节点将用于进行备份。
我已经测试并发现，只要我有完整的仅复制，以及跨越仅复制到我们想要恢复到的时间的日志备份链，我就可以进行时间点恢复。
我们不使用差速器，也没有计划。
除了可能无法在没有“正常”备份的情况下缩小数据文件之外，我看不出这种方法的任何缺点。我们通常不会缩小我们的数据库，除非我们做一些事情来破坏它们，到那时我们无论如何都处于干预模式。
所以我的问题是，我会后悔走这条路吗？
我们最近将生产设施升级到 SQL Server 2017，并迁移到无集群可用性组。有一个主要设备、一个现场辅助设备和一个远程辅助设备。我们遇到与远程辅助同步的周期性中断。带宽低至6G，sql流量与所有其他流量竞争。好消息是AG会在5-15分钟后“追上”。在研究是否可以采取任何措施来改善这种情况时，我通过实验发现网络 MTU 为 1400，并且 sql 的网络数据包大小设置为默认值 4092。作为实验，我将数据包大小设置为 1400 以匹配MTU。我们已经好几天没有收到有关 AG 的警报了，所以它“似乎”得到了帮助。
我的问题是这样做是否正确？我已经读过很多次，除非 MS 也建议你，否则不要更改网络数据包大小，并且永远不要将其设置为小于默认值 4096。然而......它似乎有所帮助。因此，我正在寻找类似情况下更有经验的人的意见。
背景：
我的部门正在从带有镜像的 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 的小型组织，需要对所采取的行动有所选择。