December 30, 2018 at 7:10 am
Hi,
I am looking for an advice.I am planning an AG upgrades to 2017.I read in many places that I should go for rolling upgrade.
I am planning to upgrade from 2012 with 2 synch replicas.If I upgrade one of the synch replica(passive), I understand its available only in read mode.So I wont be able to do an end to end testing in my replica after upgrade(like read insert operatiosn etc done by application)
In this case if I do a manual fail over to the upgraded replica by keeping my prev active node with out upgrade(until I get a sign off that no issues faced in the upgraded node,)
My question- if some one reported an issue in the upgraded node, can I fail back to one of the non upgraded replica? or it wont allow a fail back from my upgraded 2017 to non upgraded 2012?
Appreciate if any one can give me an answer.
thanks
December 30, 2018 at 10:30 pm
sdavis754 - Sunday, December 30, 2018 7:10 AMHi,
I am looking for an advice.I am planning an AG upgrades to 2017.I read in many places that I should go for rolling upgrade.
I am planning to upgrade from 2012 with 2 synch replicas.If I upgrade one of the synch replica(passive), I understand its available only in read mode.So I wont be able to do an end to end testing in my replica after upgrade(like read insert operatiosn etc done by application)In this case if I do a manual fail over to the upgraded replica by keeping my prev active node with out upgrade(until I get a sign off that no issues faced in the upgraded node,)
My question- if some one reported an issue in the upgraded node, can I fail back to one of the non upgraded replica? or it wont allow a fail back from my upgraded 2017 to non upgraded 2012?
Appreciate if any one can give me an answer.
thanks
Having a two different versions mostly uses in upgrade. I do not think the fail back will work from higher version to lower.
Muthukkumaran Kaliyamoorthy
https://www.sqlserverblogforum.com/
January 16, 2019 at 3:55 am
You can refer below link for AG upgrade.But I think failback from Hogher version to lower version will not be possible.
January 16, 2019 at 5:12 pm
The failback from higher to lower will not work. Once you failover, the database is recovered on the 2017 replica and cannot be downgraded. The database on the 2012 replica will also cease to synchronise with the primary replica because of this version difference.
In the event of rollback, the only option is retsore from backup or you must remove the database from the AG, bring the database online on the 2012 replica (RESTORE WITH RECOVERY) and fail over the AG (without database(s)) back to the 2012 replica. Provided your applications are connecting via the listener, they will reconnect to the recovered database at the point of the original failover to 2017 but on the original 2012 replica.
The best solution is to perform the upgrades in your lower environment and undertake sufficient application testing as the rollback method does leave you in an somewhat dangerous state. Having to rebuild your 2012 secondary replica takes time and for this period, you are without your HA\DR replica.
When upgrading AG environments, I usually look to add at least two new replicas in on the higher version, then if I have to rollback my upgrade, it is as a simple as recovering the database as described above, ejecting the new version replicas and then reinitialising the database(s) back into the AG with only the original version replicas. This is quicker than rebuilding my secondary with the original version. If my upgrade is successful, I can simply eject the old version replicas and my AG is still live and running on the new version with minimal interruptions.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply