SQL Server 2022: AlwaysOn AG databases can not sync after applying CU6 or higher

[Tom_HJ]

The setup is:
OS - Win Server 2022 & MSSQL - SQL Server 2022
AlwaysOn Availability Groups are enabled on two (primary + secondary) replicas and use WSFC.
Several availability groups are created and a database in each of them. 
AGs are configured with Sync Commit and Automatic failover mode, also they use dedicated separate VLAN for data sync.

The issue we noticed is that after applying CU6 or higher ones , in case of we restart any of two replica hosts,
on the secondary replica not all databases switch back to Synchronized state, part of them remain in Not Synchronizing state .

Any ideas what could be the reason of that behavior change? Had someone similar issue ?

[#2]

Hello

Are the databases not syncing having Filestream or Filetable enabled ?
If that is the case there is a bug in SQL 2022 and you have to enable a global traceflag. Not sure if this is your case but just have a look

https://www.seangallardy.com/sql-server-2022-distributed-availability-groups-and-filestream/


Regards
Javier

[#3]

Hi
We do not have Filestream or Filetable enabled for the databases and also availability groups have basic settings.

[#4]

as an additional info, the following event appears in the sql server error logs while sql server tries to sync databases after the replica restart:

Could not process the operation. Always On Availability Groups replica manager is waiting for the host computer to start a Windows Server Failover Clustering (WSFC) cluster and join it. Either the local computer is not a cluster node, or the local cluster node is not online. If the computer is a cluster node, wait for it to join the cluster. If the computer is not a cluster node, add the computer to a WSFC cluster. Then, retry the operation.

[#5]

Try to run the cluster validation wizard to see if the configuration for the windows cluster is OK. is quite weir to have these errors
Do you have all the nodes online in Cluster Manager ?
I doubt it is related to the SQL CU
Maybe is a good idea to open a support case for this

Regards
Javier