We have a three node Always On Availability Group cluster. We normally patch the passive nodes (N2, N3), fail over from N1 to N2, patch N1, and then fail back to N1. N1 and N2 are sync, N3 is async.

I am in a argument with our colleagues on weather to fail back to node 1 after patching. My colleagues say we have to do this, so that we make sure Node 1 is functional. I am of the opinion that we keep SQL Server on N2 so that we avoid another interruption of failing over to N1.

I was wondering if the practice of failing back to N1 to make sure the node is healthy is warranted or just useless?

  • 1
    By that reasoning why wouldn't you also test N3? – Michael Green Mar 17 '18 at 19:24

To be honest there is no definite answer to your question.

If you do the last fallback to N1 you tested it on all available nodes. Within limits, more testing seems to be better to me. But to be honest it might not be absolutely necessary.

Leaving it on N2 will get you the added benefit of using the N2 node for primary workload until the next update.

It might even be feasible to do the fallback to N1 and then do another failover to N2 to test if N1 is running and then have N2 as primary until the next update.

In conclusion: I don't think it is absolutely necessary to the fall back to N1 but if you can afford the time during your maintenance window I would consider just doing it (and maybe even do the failover to N2 afterwards).

| improve this answer | |

The goal of AlwaysOn is to have the minimum down time. In your case, no need to failback to N1

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.