December 22, 2023 at 2:21 pm
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 ?
December 23, 2023 at 3:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
December 27, 2023 at 3:56 pm
To start - CU6 is an unsupported CU. You would need to be at least up to CU8. Is Windows also held back more than two CU?
December 27, 2023 at 5:26 pm
We experience the issue on higher sql server CUs as well, for example CU10 in our case, what relates to Windows patch level on replicas, those have the latest CU update.
January 4, 2024 at 8:35 am
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 ?
You have mentioned that some are synchronized state and some not. Do you find any similarity between those non-syncing databases?
January 4, 2024 at 9:15 am
We could not see similarity between not synced databases, but as an additional info -
the following event appears in the sql server error logs after the replica restarts:
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.
January 4, 2024 at 5:23 pm
What do the failover clustering logs say? (you may want to try clearing them to let fresh logs reaccumulate if the log file is excessively large)
January 14, 2024 at 12:44 pm
I think Known Issue: Check Microsoft's release notes for CU6 and later for known issues related to AlwaysOn AG synchronization. Apply any available hotfixes.
Review Error Logs: Examine SQL Server and WSFC logs for specific error messages that could pinpoint the problem.
Network Connectivity: Verify network connectivity between replicas and rule out firewall or VLAN configuration issues.
CU6 Changes: Research any changes introduced in CU6 that might affect AG synchronization behavior.
Microsoft Support: Engage Microsoft support for in-depth investigation and assistance if the issue persists. Sorry for the late response. Please let me know if it works yes or not.
March 8, 2024 at 11:25 am
This was removed by the editor as SPAM
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply