Patch an availability group in the wrong order and you find out at the worst possible moment. Patching an availability group is a sequence, not a single installer run: secondaries first, health checked, a deliberate failover, then the old primary.
Map Every Replica Before the Window
List every replica, its current role, commit mode, failover mode, and server build. Include any distributed availability group or failover cluster instance in the topology. A simple two replica diagram can hide an asynchronous disaster recovery replica or a shared host. The patch order depends on the real layout.
Almost every availability group I am asked to patch has one replica somebody forgot about, usually the asynchronous one in the other data center.
Record which node is primary for each availability group. A server can host several groups and be primary for one while secondary for another. A change that looks safe for one group can interrupt another. Check readable secondary workloads and backup preferences. Reporting and backup jobs need their own plan during a rolling patch.
Microsoft’s rolling upgrade guidance puts remote secondaries first, local secondaries next, and the primary last. Adapt the detailed runbook to your topology and version. Keep one owner for the sequence so separate teams do not patch in conflicting order.
SELECT
ag.name AS AvailabilityGroup,
ar.replica_server_name,
ar.availability_mode_desc,
ar.failover_mode_desc,
ars.role_desc,
ars.synchronization_health_desc
FROM sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
ON ag.group_id = ar.group_id
LEFT JOIN sys.dm_hadr_availability_replica_states AS ars
ON ar.replica_id = ars.replica_id
ORDER BY ag.name, ar.replica_server_name;Prepare Backups and Failover Before Patching an Availability Group
Take and verify backups of the availability databases. Back up system databases and document jobs, logins, and linked servers on each instance. Availability groups replicate user database changes, not every server object. A failed over application can fail at login or job execution even when the database is synchronized.
Practice manual failover in a test environment. Confirm the listener, driver, and application reconnect behavior. If the group uses synchronous commit, make sure the intended target reaches SYNCHRONIZED before a planned failover. Do not choose an asynchronous target for a routine no data loss failover.
Review backup preferences before patching a secondary. A backup job assigned to a replica that is offline for servicing needs to move or pause. Keep a clear record of which backup completed before the window and which one is due afterward.
Start Patching an Availability Group at the Remote Secondary
Drain read only traffic and pause jobs that depend on the selected secondary. Apply the exact CU package approved in test. Restart as required. Verify the Database Engine build, SQL Server error log, Agent service, and availability group connection. Do not proceed while the replica is disconnected or unhealthy.
Wait for data movement to catch up. Check synchronization state for every database in the group. A replica role of SECONDARY alone is not enough. One database can be suspended while others look healthy. Investigate a suspended database before patching another node.
Remote asynchronous secondaries have a different recovery role from local synchronous ones. Do not treat a healthy asynchronous replica as an immediate no data loss failover target. Patch it early, then allow it to catch up and confirm your disaster recovery protection is restored.
SELECT
DB_NAME(database_id) AS DatabaseName,
is_local,
synchronization_state_desc,
synchronization_health_desc,
is_suspended
FROM sys.dm_hadr_database_replica_states
ORDER BY database_id, is_local;
Patch Local Secondaries and Recheck
Move to local secondaries only after the prior replica is stable. Patch one instance at a time. Compare the running ProductVersion with the approved target. Confirm every availability database resumes data movement and reaches the expected synchronization state. A cluster dashboard can hide one lagging database, so check at database level.
If automatic failover is configured, follow the documented procedure for controlling unintended failover during the rolling update. Coordinate that change with the cluster owner. Do not quietly alter failover mode without a plan to restore it. Record the original values before making temporary changes.
Check application read only routing if you use readable secondaries. A replica can be healthy for data movement while reports fail because routing, permissions, or application connections changed. Test the paths that actually serve users.
Fail Over Deliberately
Once an updated local synchronous secondary is SYNCHRONIZED, schedule the planned manual failover. Pause application writes or coordinate the brief interruption as required by the application. Fail over to that updated secondary. Confirm the listener points to the new primary and that the application reconnects.
Check every availability database is online and writable on the new primary. Verify jobs that run only on the primary. Check backups and monitoring alerts. A successful cluster role switch does not prove that the complete application is healthy. The handoff is a test case, not just a button.
Do not continue if the new primary has an unresolved error. Investigate and decide whether to remain there or use the documented recovery path. That decision belongs in the maintenance plan before patch night.
SELECT
@@SERVERNAME AS ConnectedInstance,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('HadrManagerStatus') AS HadrManagerStatus;Patch the Former Primary
The old primary is now a secondary. Drain any remaining connections and apply the CU. Restart as required. Verify the full build and wait for every database to rejoin and synchronize. This is the point where the group returns to a consistent servicing level.
If you plan to fail back to the original primary, do it as a separate controlled step after health checks. Another planned failover creates another interruption. Do not add it automatically for the sake of a familiar server name. The application should use the listener, not rely on a specific node.
Restore the intended failover modes, backup preferences, and read only routing. Remove any temporary job pauses. Compare the final topology with the pre patch map. A rolling patch is unfinished until operations behave as expected on the new arrangement.
Know When to Stop Patching an Availability Group
Stop the sequence if setup fails, a replica will not synchronize, a database is suspended, or the application fails after failover. Keep the primary on a healthy node while you diagnose the next step. Patching another replica during an unexplained failure reduces your options.
I decide the stop point before the window opens. Which replica would you leave on the old build if the second one failed? Write that answer down while everyone is calm.
Stopping halfway, on purpose, is a perfectly good outcome. A cluster on mixed builds with a clear note is easier to live with than one that finished at 4 a.m. with nobody sure what happened.
Save version queries, setup summaries, replica health output, and application checks at each stage. These notes help the next shift and support a clean incident report. They also prove which node received the CU if setup behavior differs.
I keep the runbook for patching an availability group readable enough to use at a maintenance window. Each line has an action, a verification, and a stop rule. The order protects availability only when every checkpoint is honored.
Related reading on this blog: How to Apply Patch in AlwaysOn Availability Group Configuration? and How to Patch SQL Server Without a Bad Morning.
An availability group patch is not a race through nodes, it is a series of verified handoffs.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
