Share via

SQL Server Cluster Sync Issue After Windows Patch KB5091157

ITD-Sreng Channy 0 Reputation points
2026-05-22T02:04:04.07+00:00

I have an issue related to patching Windows Server 2025. After installing patch KB5091157, our Microsoft SQL Server cluster cannot sync.

Details:

  • What happened: The SQL cluster worked fine before the patch. After patching, the cluster will not sync.
  • Impact: Databases in the cluster are not syncing.
  • Request: Please help fix the cluster and restore synchronization.

Thank you.

SQL Server Database Engine
0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-05-22T02:04:27.94+00:00

    Perform these steps to restore cluster and database synchronization after the Windows Server 2025 patch:

    1. Validate the Windows Failover Cluster
      • Open Failover Cluster Manager.
      • Under Management, select Validate a Configuration.
      • Run the validation tests and review the Validation Report for errors, especially in networking and storage.
      • The report is saved under %SystemRoot%\Cluster\Reports\Validation Report date and time.html.
      • Fix any issues reported (network, storage, or configuration) before proceeding.
    2. Check common cluster connectivity and disk issues
      • If SQL Server cannot connect to the network after failover or node changes:
        • Check event logs for adapter failures or DNS problems and verify the cluster nodes can reach domain controllers (ping tests, DNS resolution).
        • Ensure SQL Server service account passwords are identical on all nodes by changing them via SQL Server Configuration Manager so all nodes stay consistent.
      • If SQL Server cannot access cluster disks after the patch:
        • Verify firmware and drivers are updated and consistent on all nodes.
        • Confirm that drive letters for all cluster disks are identical on every node; mismatched drive letters will prevent proper failover and synchronization.
    3. Confirm FCI/AG configuration consistency
      • For a failover cluster instance (FCI):
        • Ensure all nodes still have identical OS version/patch level and SQL Server version/patch level and components after the patch.
        • Confirm the WSFC resource group for the SQL FCI is online on one node and that shared storage is accessible from all nodes.
      • For Always On AG on top of WSFC:
        • Use the AG dashboard in SQL Server Management Studio to check replica states.
        • If a replica is stuck in SYNCHRONIZING, verify whether it is configured as synchronous or asynchronous; only synchronous replicas can reach SYNCHRONIZED.
    4. Recover from node or cluster failure if needed
      • If one node is effectively unusable after the patch (for example, cannot rejoin the cluster):
        • Let the SQL Server FCI or AG run on the healthy node.
        • From the healthy node, use Failover Cluster Manager to evict the failed node from the cluster.
        • Repair or rebuild the failed node (including OS and SQL Server), then add it back to the cluster and to the FCI/AG using SQL Server Setup.
    5. Address known synchronization and lease issues (if applicable)
      • If using Always On Availability Groups and seeing repeated lease or synchronization failures after the patch:
        • Review cluster and SQL logs for lease timeout or synchronization errors.
        • Ensure antivirus or security tools are not scanning critical cluster and SQL paths (for example, C:\Windows\Cluster, SQL data/log directories, and SQL binaries), as this can cause timeouts and lease expirations.
        • If lease timeouts are observed, consider temporarily increasing the AG lease timeout via the AG resource properties in Failover Cluster Manager, then revert once stability is confirmed.
    6. Apply relevant SQL Server cumulative updates
      • If the environment matches known issues (for example, synchronization failures in specific SQL Server builds), install the latest cumulative update for the SQL Server version in use, as many synchronization and AG/FCI issues are fixed in CUs.

    After these steps, re-check the AG dashboard and Failover Cluster Manager:

    • All cluster resources should be online.
    • Databases on secondary replicas should show SYNCHRONIZED (for synchronous replicas) and data changes should be flowing from primary to secondary.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.