February 4, 2016 at 12:15 pm
Question for the group.
We just setup a new SQL 2014 SP1 system with two servers and have all of the databases setup in AlwaysOn. My question is when it comes time to apply a service pack or a CU do you have to take all of the databases out of the AG, apply the patch to both nodes, restart, then put the databases back into it? Or, can you patch the secondary, fail over to that, then apply the patch to the other node?
Just curious about this as I haven't seen anything about this topic yet.
Has anyone actually patched an Always On system between two servers?
February 4, 2016 at 12:37 pm
Entire purpose of AAAG is to have high availability. You can fail over your AG to another node, patch primary , fail back to primary once patching is done and patch secondary.
February 4, 2016 at 1:22 pm
1. Open your Windows FailOver Cluster Manager .
2. Check which node owns the Role (A or B).
3. Pause the Secondary node (so that the Primary knows is down)
4. Patch the Secondary node.
5. Reboot if required.
6. Check for more patches or updates (reboot if required)
7. If none needed then RESUME the secondary node.
8. Failover using High Availability Failover Wizard (SQL AlwaysON Dashboard)
9. Pause the other node (which should be Secondary) on Windows Cluster Manager
10. Apply Patches and updates
11. Reboot if required
12. Check for additional patches (reboot if required)
13. RESUME node again in Windows Failover Cluster Manager
14. Failover back to original node if want to keep in perspective (A being primary B Secondary)
February 4, 2016 at 3:57 pm
jcarranza 23978 (2/4/2016)
1. Open your Windows FailOver Cluster Manager .2. Check which node owns the Role (A or B).
3. Pause the Secondary node (so that the Primary knows is down)
4. Patch the Secondary node.
5. Reboot if required.
6. Check for more patches or updates (reboot if required)
7. If none needed then RESUME the secondary node.
8. Failover using High Availability Failover Wizard (SQL AlwaysON Dashboard)
9. Pause the other node (which should be Secondary) on Windows Cluster Manager
10. Apply Patches and updates
11. Reboot if required
12. Check for additional patches (reboot if required)
13. RESUME node again in Windows Failover Cluster Manager
14. Failover back to original node if want to keep in perspective (A being primary B Secondary)
are you talking pausing the cluster service on the node itself in FCM?
This should not be used, if you happen to have an FCI running on the same node (or indeed any other clustered resource) that's part of another AG or just running on that node you'll kill that too.
The rolling upgrade process is applied to patching an AG, it's quite involved so here's the KB from Microsoft on how to complete this
https://msdn.microsoft.com/en-gb/library/dn178483.aspx
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 4, 2016 at 4:09 pm
•To prevent the availability group from unintended failovers during the upgrade process, remove availability failover from all synchronous-commit replicas before you begin.
February 4, 2016 at 4:16 pm
jcarranza 23978 (2/4/2016)
•To prevent the availability group from unintended failovers during the upgrade process, remove availability failover from all synchronous-commit replicas before you begin.
remove the automatic failover flag where it's set, that's all that is required, this prevents unexpected failovers even to a synchronous replica
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 5, 2016 at 5:57 am
jcarranza 23978 (2/4/2016)
1. Open your Windows FailOver Cluster Manager .2. Check which node owns the Role (A or B).
3. Pause the Secondary node (so that the Primary knows is down)
4. Patch the Secondary node.
5. Reboot if required.
6. Check for more patches or updates (reboot if required)
7. If none needed then RESUME the secondary node.
8. Failover using High Availability Failover Wizard (SQL AlwaysON Dashboard)
9. Pause the other node (which should be Secondary) on Windows Cluster Manager
10. Apply Patches and updates
11. Reboot if required
12. Check for additional patches (reboot if required)
13. RESUME node again in Windows Failover Cluster Manager
14. Failover back to original node if want to keep in perspective (A being primary B Secondary)
In the Pause node... it says Drain roles or do not drain roles? What is the difference between the two options?
February 5, 2016 at 8:22 am
Normally when you do the FailOver on the AlwaysON High Availability Group the Primary Node A will change the ROLE over to Node B.
If you don't do it through the SQL GUI you can failover using the FailOver Cluster Manager. Normally the primary Node will own the AlwaysON HA Group ROLE. So if NODE A is the Primary it will own the ROLE. If You pause B (you don't have to drain the ROLE) since it is secondary and it does not own the ROLE. If you were to pause the Node A, since it is the Primary you can DRAIN the ROLE and it will move it to the Secondary. Now NODE B will be Primary and it will own the ROLE.
In other words if you were to check the Failover Cluster Manager and look at ROLES it will tell you which node owns the ROLE (Node A or Node B). Which in term it should coincide which Node is Primary (A or B).
Hope I explained myself.
February 5, 2016 at 8:25 am
jcarranza 23978 (2/5/2016)
Normally when you do the FailOver on the AlwaysON High Availability Group the Primary Node A will change the ROLE over to Node B.If you don't do it through the SQL GUI you can failover using the FailOver Cluster Manager. Normally the primary Node will own the AlwaysON HA Group ROLE. So if NODE A is the Primary it will own the ROLE. If You pause B (you don't have to drain the ROLE) since it is secondary and it does not own the ROLE. If you were to pause the Node A, since it is the Primary you can DRAIN the ROLE and it will move it to the Secondary. Now NODE B will be Primary and it will own the ROLE.
In other words if you were to check the Failover Cluster Manager and look at ROLES it will tell you which node owns the ROLE (Node A or Node B). Which in term it should coincide which Node is Primary (A or B).
Hope I explained myself.
Great, that answered it perfectly.
February 5, 2016 at 8:26 am
Perry, I don't have multiple AG Groups on my servers.
I'm conscious of what you are saying.
one AG Group is just pure SharePoint. All DBs failover.
Another it has multiple DBs for different applications but only one AG Group.
Same for the other two AG Groups.
They are all virtualized on VMWare.
February 5, 2016 at 8:29 am
Again, pausing the cluster node is not recommended. If you happen to have other cluster resources running in this node you'll initiate a failover.
The link posted from Microsoft describes the correct way to patch availability groups
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 5, 2016 at 8:31 am
What Perry is referring is that when you go to the Properties of the Availability Group you can change the Failover Mode from Automatic to Manual.
But if I change the Node on the Cluster to Pause. The Cluster will be aware that Node B is down and therefore will not failover.
or if you change the FailOver Mode to Manual (in the AG Properties). Either way it works without a problem.
February 8, 2016 at 12:06 pm
February 9, 2016 at 4:43 am
:Whistling: I posted the link to that at the beginning of this topic on my very first post :w00t:
At no point does it tell you to pause cluster nodes, it does however, direct you to ensure that all replicas are synchronised during the upgrade process by change synchronisation modes between the replicas.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 10, 2016 at 5:45 am
Perry Whittle (2/9/2016)
:Whistling: I posted the link to that at the beginning of this topic on my very first post :w00t:
At no point does it tell you to pause cluster nodes, it does however, direct you to ensure that all replicas are synchronised during the upgrade process by change synchronisation modes between the replicas.
You are right... sorry.. You posted it before I did. LOL.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply