NOTE: Always test any solution in Lower life cycle environment before deploying it to Production.

Points to Remember

1. I have described steps to upgrade or patch SQL Server failover cluster instance having always on availability group. Do not use these steps while upgrading or patching Windows clustering or standalone SQL Server instances running with Always on Availability groups. If you have AOAG configured on standalone SQL Server instances then read attached article.
2. During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic).
3. A higher version of a SQL Server instance cannot be added as a new replica to an existing AOAG. For example, a SQL Server 2016 replica cannot be added to an existing SQL Server 2014 AG.
4. Always first upgrade secondary replica then primary replica because an upgraded primary replica can no longer ship logs to any secondary replica. This may cause data loss as data movement to a secondary replica is suspended.

Planning 

We should be very careful while planning upgrade or Patching for your SQL Server Failover cluster instances and if your SQL Server cluster instances are running with availability groups then you need to be more careful considering its complex configuration. Here, i have given multiple steps that you need to plan during patching any AOAG cluster instance.

1. Make sure you can directly upgrade to the latest version of SQL Server 2017. If you are running with SQL Server 2005, you cannot go directly to SQL Server 2017. You must upgrade SQL Server 2005 to SQL Server 2012, 14 or 2016 before moving to latest version SQL Server 2017.
2. Identify your databases if they are involved in Change Data Capture or Replication then we need to perform some additional activities. These additional steps are given later in this article.
3. Run DBCC CHECKDB to make sure there is no corruption on databases hosted on these cluster instances.
4. You must run Full database backups for all your databases to secure a copy in case anything goes wrong and we need it to restore databases.
5. Make sure Always on Availability Group is working fine and in Healthy state. Fix the issues and make your AOAG configuration in healthy state before going with the upgrade.
6. Disable the backup job from the system that is going to upgrade (current secondary replica) and make sure to run it from the server that is online and acting as primary replica at the time upgrade will process. You can also change the Backup Preferences of AOAG to run backups always from primary replica during this upgrade.
7. No replicas are readable or available for backups during a version upgrade whereas during a non-version upgrade you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.
8. Choose Upgrade approach. As we know, there are three approaches to perform any SQL Server upgrade. In-place upgrade, Side by side upgrade and Rolling upgrade. We will be using rolling upgrade process to apply patch or upgrade SQL Server cluster instances. This approach is used if your SQL Server Instances are required to upgrade in particular sequence. We use this approach if SQL Server is configured with Always on availability group, Database Mirroring, Log Shipping, Replication, Failover Cluster Instances, SQL Server Reporting Scale-out environment.
9. Make sure that synchronization state of the failover target is SYNCHRONIZED during any failover of Availability Group.
10. Develop a rollback plan. Executing this plan will enable you to restore your original environment if you need to rollback.
11. Plan to test the upgrade on Lower life cycle first before deploying on productions.

Upgrade or Patch SQL Server Failover Cluster Instance running with Availability Group

Here, I will explain how to upgrade or patch SQL Server failover cluster Instance running with Always on Availability group. Let me describe the cluster setup first for this upgrade.

• We have four database servers that are hosted in two data centers. Two nodes in each data centers.
• All four nodes are part of same windows cluster group. two set of storage have been shared between two nodes to install SQL Server failover cluster.
• Two SQL Server Failover Cluster Instances have been installed on these nodes of each data centers. One SQL Server failover cluster instance named FCIA is installed in data center 1 and another SQL Server cluster instance named FCIB is hosted in data center 2.
• We have configured Availability Group between these two SQL Server failover cluster instances.
• Each SQL Server cluster instance has two nodes. One active and one passive node in their respective data centers. Although active node in data center 2 is not active for connections but this will work as primary in case AOAG failover.
• Databases are hosted on shared storage that is connected to their respective nodes in their data centers. You can see this configuration depicted in below image.

Now we have to upgrade or patch this AOAG cluster instance configuration. Keep reading this article to understand step by step process to patch such complex AOAG configuration.

We can see above SQL Server cluster instances have Always on Availability Group so we will follow rolling upgrade process to perform upgrade or patch on these SQL Server cluster instances. The sequence to upgrade SQL Server cluster instances having AOAG configuration is to go from passive to active. We will upgrade the inactive nodes before upgrading the active nodes. Have a look at below step by step process.

1. First upgrade or patch passive node of SQL Server cluster instance FCIB i.e. Node 4.
2. Once you will update node 4 of above image configuration then next step is to failover second SQL Server cluster instance FCIB to upgraded instance Node 4 that is hosted in data center 2.
3. Once you performed failover for cluster instance FCIB to node 4 then next step is to patch node 3 that will be in passive state of this inactive SQL Server cluster instance. You can failback SQL Server cluster instance FCIB to node 3 again post patching. This failback is an optional step and not mandatory. Now you have applied latest patch level or upgraded your SQL Server cluster instance FCIB hosted in two cluster nodes in data center 2. Next, we will follow same process to apply patches in data center 1.
4. Apply patch on SQL Server cluster node 2 or upgrade SQL Server cluster node installed on node 2 machine as it’s passive node of SQL Server cluster instance FCIA.
5. Once you have upgraded or patched node 2 in data center 1 next we will failover SQL Server cluster instance FCIA to node 2. Now node 2 will run active instance of SQL Server cluster setup. But If you have enabled change data capture feature or replication configured on your SQL Server cluster instance then you should run few additional steps as described here. Once you upgraded or patched all secondary replicas then fail over the Availability Group to an upgraded instance. Now run below command on your primary replica.

EXECUTE [master].[sys].[sp_vupgrade_replication];

6. Go ahead after execution of above command and upgrade or patch SQL Server cluster instance that was originally the primary replica i.e. Node 1

7. Now, patch SQL Server cluster instance that is hosted on node 1 and was original primary replica that is now acting as passive in this cluster setup. Once done you can failback SQL Server cluster instance FCIA to again node 1 as active node. Here, you have patched or upgraded all SQL Server cluster instances hosted on these four nodes.

Here, I have described how to upgrade or patch SQL Server failover cluster instance that is running with Always on Availability Group. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to Restore a Database participating in AOAG?
• SQL Server Alwayson Interview Questions & Answers
• Change Failover Mode of Availability Replica in AOAG
• Add a New Database to Availability Group

The post Upgrade or Patch SQL Server Failover Cluster Instance Running with Availability Group appeared first on Techyaz.com.

NOTE: First Test this solution in Lower Life Cycle environment then deploy in Production.

Points to Remember 

Below are important points you should always keep in mind while you are planning or upgrading SQL Server Instances that has Alwayson Availability Group configured.

1. All steps given in this article are limited to upgrading or patching SQL Server Instances that has AOAG configuration. It does not cover operating system upgrade.
2. Secondary replica will not be available for failover or for read-only operations during the upgrade process.
3. A higher version of a SQL Server instance cannot be added as a new replica to an existing AOAG. For example, a SQL Server 2016 replica cannot be added to an existing SQL Server 2014 AG.
4. Don’t upgrade primary replica instance before upgrading or updating any other secondary replica instance. An upgraded primary replica can no longer ship logs to any secondary replica. This may cause data loss as data movement to a secondary replica is suspended.

Upgrade or Patch SQL Server AOAG Instances – Prerequisites

Make sure to meet and follow below prerequisites during planning the upgrade or patching of SQL Server Availability Group Instances.

1. Review the Hardware and software requirements for latest SQL Server version on which you are planning to upgrade.
2. Make sure your application is supported on the latest version of SQL Server on which we are upgrading.
3. Make sure you can directly upgrade to the latest version of SQL Server 2017. If you are running with SQL Server 2005, you cannot go directly to SQL Server 2017. You must upgrade SQL Server 2005 to SQL Server 2012, 14 or 2016 before moving to latest version SQL Server 2017.
4. Choose Upgrade approach. As we know, there are three approaches to perform any SQL Server upgrade. In-place upgrade, Side by side upgrade and Rolling upgrade. As we are planning to upgrade AOAG instance so we will choose Rolling Upgrade method. Below are the details of other upgrade methods.

• In-Place Upgrade: SQL Server setup program upgrades the existing SQL Server installation by replacing the existing SQL Server bits with the new SQL Server bits and then upgrades each of the system and user databases. This method is frequently used in a development environment without a high-availability (HA) configuration or a non-mission critical production environment that can tolerate downtime and that is running on a recent hardware and software.
• Side by Side Upgrade: We build new machine and install all required software keeping source system running separately and then migrate all databases from source to this newly build machine. This method is effective in minimizing the downtime or in case if you need to roll back the upgrade.
• Rolling Upgrade: This method is used if your SQL Server Instances are required to upgrade in particular sequence. We use this approach if SQL Server is configured with Always on availability group, Database Mirroring, Log Shipping, Replication, Failover Cluster Instances, SQL Server Reporting Scale-out environment.

5. Develop a rollback plan. Executing this plan will enable you to restore your original environment if you need to rollback.
6. Plan to test the upgrade on Lower life cycle first before deploying on productions.
7. Identify your databases if they are involved in Change Data Capture or Replication then we need to perform some addition activities. Have a look into last section of this article before performing the upgrades.

Upgrade or Patch AOAG Instances – Planning

Here, I am explaining how to plan SQL Server Availability Group instance patching or upgrade to the newer version. Have a look at below points.

1. Check database integrity on every availability databases that we are going to upgrade. Run DBCC CHECKDB to make sure there is no corruption on databases.
2. Run Full database backups for all your databases to secure a copy in case anything goes wrong we need it to restore databases.
3. Make sure Always on Availability Group is working fine and in Healthy state. You can test a manual failover whether it is working fine or not. If any issue during failover or AOAG not in healthy state, you must fix it before going with the upgrade.
4. Disable the backup job from the system that is going to upgrade (current secondary replica) and make sure to run it from the server that is online and acting as primary replica at the time upgrade will process. You can also change the Backup Preferences of AOAG to run backups always from primary replica during this upgrade.
5. The sequence will be always upgrade the remote secondary replica instances first, then local secondary replica instances next, and the primary replica instance last. If you upgrade the primary replica instance without failing over the Always on availability Group to an upgraded instance with a secondary replica then client applications may suffer extended downtime during the upgrade on the primary replica instance. So better to follow the sequence to reduce downtime.
6. Always failover the AOAG to a synchronous-commit secondary replica instance. If you fail over to an asynchronous-commit secondary replica instance, you might lose some of your data.
7. Make sure that synchronization state of the failover target is SYNCHRONIZED during any failover of Availability Group.

Upgrading or Patching Always on Availability group Instances

Now you have planned and understand the rolling upgrade methodology and the upgrade process of AOAG configured SQL Server Instances. Here, i will explain upgrade or patching of availability group instances into two sections. One has multiple secondary replicas and another have only one secondary replica that also in remote location for DR purpose.

If Availability Group has Local and Remote Secondary Replicas

Here, I am giving a standard process to perform the upgrade on a configuration that has local secondary replicas as well as remote secondary replicas for DR solution. You can consider it as four replica environments where one replica is hosted on local datacenter and remaining other replicas are hosted on one or multiple remote sites for DR purpose. I have illustrated this configuration in below screenshot where we have one local replica and two remote secondary replicas.

Let’s start with upgrade process considering above scenario.

1. Verify you have full database backup for all availability databases. If you don’t have full backups, make sure to run it before this upgrade to protect your data.
2. Now, change automatic failover on synchronous-commit replicas to manual (between replica A and B) to prevent any accidently failovers during upgrade process.
3. Test a manual failover and make sure that it is working fine.
4. Now upgrade all remote secondary replica instances (Replica C and D) running with asynchronous-commit secondary replicas.
5. Upgrade the all local replica secondary instances (Replica B) that are not currently running the primary replica.
6. Once all secondary replicas have been upgraded and you left out only with primary replica to upgrade then manually fail over the AG to a local synchronous-commit secondary replica. Here, Replica B will be acting as primary replica now.
7. Upgrade or update the local replica instance that formerly hosted the primary replica (Replica A).
8. Verify SQL Server version on all replicas to make sure every instance is upgraded. Failback current primary replica from replica B to A that was primary replica initially.
9. Now, configure automatic failover partners from manual failover (between replica A and B) as we did in step 2 to prevent unwanted failover during upgrade process.
10. Perform a failover testing on upgraded instances to make sure everything is working fine.

If Availability Group has only One Secondary Replica for DR solution

If you have configured Availability group only to achieve DR solution having single remote secondary replica with asynchronous-commit mode then you need to follow little different approach for upgrade or apply patches.

You can follow below step by step method to upgrade or Patch your AOAG instances that has only one secondary replica that also on remote site for DR purpose.

1. Verify you have full database backups to secure your data.
2. Upgrade your remote secondary replica that is hosted for DR.
3. Once remote secondary replica is upgraded or Patched, make sure to change the data transfer mode from asynchronous-commit to synchronous-commit to prevent any potential data loss during failover. Do not initiate failover until synchronization state will become SYNCHRONIZED.
4. Initiate the failover once data is synchronized between both replicas. And once failover will be done again change the data transfer more to asynchronous-commit mode to avoid any data latency issue to application users.
5. Upgrade the current secondary replica (Previous Primary Replica).
6. Once both replicas will be upgraded, you can again change the data transfer mode from asynchronous-commit to synchronous-commit to prevent any potential data loss during failover. Do not initiate failover until synchronization state will become SYNCHRONIZED.
7. Failover the AOAG to remote secondary replica and change the data transfer mode to asynchronous-commit.
8. Verify details about SQL Server version.

Additional steps for CDC (change data capture) and Replication

I have described in point no 7 of Prerequisite section to identify databases that are participating in change data capture or in Replication. I have mentioned that because we need to take some additional steps for such databases post upgrade or patching activity.

1. Upgrade each secondary replica as described in above sections.
2. After all secondary replicas have been upgraded, fail over the AG to an upgraded instance.
3. Execute below T-SQL statement on the instance that hosts the primary replica:

EXECUTE [master].[sys].[sp_vupgrade_replication];

4. Upgrade SQL Server instance that was originally configured as primary replica.

I hope you like this article. Please Like, Comment, Share & Subscribe to this website to get new articles directly into your inbox. You can also follow our Facebook page and Twitter handle to get latest updates.

The post How to Upgrade or Patch Alwayson Availability Group Instances? appeared first on Techyaz.com.