大家好，在此先感谢您的帮助。SQL Server 2017可用性组面临挑战。
背景
公司是零售B2B后端软件。大约500个单租户数据库，以及所有租户使用的5个共享数据库。工作负载特征读取最多，大多数数据库的活动很少。
托管在同一地点的物理生产服务器最近从Windows Server 2012上的SQL Server 2014 Enterprise在共享SAN / FCI配置中升级到Windows Server 2016上的SQL Server 2017 Enterprise（2插槽/ 32核/ 768 GB RAM和本地）使用AlwaysOn AG的SSD驱动器。AG业务使用带交叉电缆连接的专用10G NIC端口。
他们的要求是所有数据库都一起进行故障转移，因此他们不得不将它们全部放在一个AG中。它是同一服务器上的单个不可读取的同步副本。
新服务器已于2018年6月投入生产。安装了最新的CU（当时为CU7）和Windows更新，并且系统运行良好。大约一个月后，在将服务器从CU7更新到CU9之后，他们开始注意到以下挑战，按优先顺序列出。
我们一直在使用SQL Sentry监视服务器，没有发现物理瓶颈。所有关键指标似乎都不错。CPU平均为20％，IO时间通常小于1ms，RAM未被充分利用，并且网络<1％。
挑战性
故障转移后，症状似乎会好转，但几天后又回来了，不管哪个服务器是主要服务器-两个服务器上的症状都相同。
零星的客户端超时和连接故障，例如
建立连接时发生错误
要么
执行超时已过期
有时这些会持续40秒钟，然后消失。
事务日志备份作业完成的时间比以前长10倍。以前备份所有500个数据库的日志需要2到3分钟，现在备份需要15到25分钟。我们已经验证了备份本身可以很好地运行并具有良好的吞吐量。但是，在完成一个日志的备份之后和启动下一个日志之前会有一个小的延迟。它开始时非常低，但是在一两天内会达到2-3秒。乘以500个数据库，便有区别。
有时，一些看似随机的数据库在手动故障转移后会陷入“未同步”状态。解决此问题的唯一方法是在辅助副本上重新启动SQL Server服务，或者将这些数据库删除并重新加入AG。
CU10引入的另一个问题（在CU11中未解决）：在master.sys.databases上阻塞时，辅助超时的连接，甚至无法将SSMS对象资源管理器用于辅助副本。根本原因似乎是由Microsoft SQL Server VSS编写器发出以下查询阻止的：
select name, recovery_model_desc, state_desc, CONVERT(integer, is_in_standby), ISNULL(source_database_id,0) from master.sys.databases
观察结果
我相信我在错误日志中找到了吸烟枪。错误日志中充满了AG消息，这些消息被标记为“仅用于信息”，但看起来根本不正常，并且它们的频率与应用程序错误之间存在非常强的相关性。
错误有几种类型，并且依次出现：
DbMgrPartnerCommitPolicy :: SetSyncState：GUID
DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint：GUID
与副本数据库ID为{GUID}的可用性副本“ DB”上的主数据库“ XYZ”的辅助数据库的AlwaysOn可用性组连接已终止。这仅是参考消息。无需用户操作。
AlwaysOn可用性组与为副本副本ID为{GUID}的可用性副本“ DB”上的主数据库“ ABC”建立的辅助数据库的连接。这仅是参考消息。无需用户操作。
有时候，成千上万个。
本文讨论了SQL 2016上相同类型的错误序列，并指出这是异常的。这也解释了故障转移后的“非同步”现象。讨论的问题针对2016年，并于今年初在CU中解决。但是，除了对自动初始种子消息的引用之外，这是我可以找到的前两种消息的唯一相关参考，因为已经建立了AG，所以这里不应该这样。
这是上周每日错误的摘要，其中在PRIMARY上每种类型的错误均超过10K的日子（次要显示“与主要...的连接断开...”）：
Date Message Type (First 50 characters) Num Errors
10/8/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 61953
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 56812
10/4/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 27951
10/2/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 24158
10/7/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 14904
10/8/2018 Always On Availability Groups connection with seco 13301
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4 11057
10/3/2018 Always On Availability Groups connection with seco 10080我们有时还会看到“怪异”消息，例如：
可用性组数据库“ DB”将角色从“ SECONDARY”更改为“ SECONDARY”，因为由于角色同步，镜像会话或可用性组已故障转移。这仅是参考消息。无需用户操作。
...在从“次要”到“正在解决”的众多变化中。
手动故障转移后，系统可能会连续几天没有这些类型的消息，突然之间，由于没有明显的原因，我们将一次获得数千个消息，这反过来导致服务器变得无响应，并导致应用程序连接超时。这是一个严重的错误，因为其某些应用程序未包含重试机制，因此可能会丢失数据。当发生此类错误错误时，以下等待类型将迅速增加。这显示在AG似乎一次失去与所有数据库的连接之后的等待：
大约30秒后，所有的等待都恢复了正常，但是AG消息在一天的不同时间和不同时间（似乎是随机时间，包括非高峰时间）不断泛滥错误日志。在这些错误爆发期间，工作量的同时增加当然会使情况变得更糟。如果只有几个数据库断开连接，则通常不会导致连接超时，因为它可以独立地足够快地解决。
我们试图验证确实是CU9引发了该问题，但是我们只能将两个节点都降级为CU9。尝试将任一节点降级为CU8，导致该节点陷入“正在解决”状态，并在日志中显示相同的错误：
无法读取具有相应资源ID'...的Always On可用性组的持久配置。持久配置是由承载主可用性副本的更高版本的SQL Server编写的。升级本地SQL Server实例，以允许本地可用性副本成为辅助副本。
这意味着我们将不得不引入停机时间，以便能够同时将两个节点降级到CU8。这也表明AG有一些重大更新，可以解释我们正在经历的事情。
我们已经尝试过将max_worker_threads的默认值从0（根据本文根据我们的意见，在我们的盒子上为960 ）逐渐调整到2,000，而没有观察到对错误的影响。
我们该如何解决这些AG断开问题？有没有人遇到类似的问题？AG中拥有大量数据库的其他人是否可以在以CU9或CU8开头的SQL错误日志中看到类似的消息？
在此先感谢您的帮助！