I have an old Availability Group made up of 2 SQLServer 2016 instances (2 Windows 2016 servers in WSFC) I also have 2 new SQLServer 2017 instances (2 Windows Server 2016) that I originally wanted to join to the 2016 AG.
This is a 0 downtime migration scenario and the 2016 servers should be dismissed once the DBs were aligned on the 2017 ones.
To my great disappointment, I discovered that it is not possible to join the 2017 instances to an existing 2016 AG, but I cannot afford the burden of stopping production, taking and restoring a backup, waiting for DBs synchronization, changing the name (and possibly the ip) of the new AG to match the original one unless as the very last resource...
Then I came across the new 2016 service called "Distributed AG Group" and I started thinking about using it for my migration scenario ... basically like this:
- Create a new AG with the SQL 2017 instances
- Create a Distributed AG between the original 2016 AG and the new 2017 AG (applications continue to connect to the 2016's listener)
- Wait for the DBs synchronization to take place in the 2017 AG
- Make the 2017 AG as the primary
- Remove the 2016 AG from the Distributed AG (short applications downtime)
- Change the name and the ip of the 2017's listener (applications are up again)
- Remove the distributed AG
It is feasible? Can I mix 2016 and 2017 AGs in a Distributed AG? Or there is (obviously!) something that I'm missing and there's a simpler or more proper way to make it?