Answered by:
2016 Always On and two different domains

Question
-
Hello, newbie crossover from Oracle (database) here. So, I'm working on a project that has envisioned a primary site and a disaster recovery site (1 primary database and 1 standby database (total, not per site)). The primary site uses one domain and the secondary site uses another. From what I've read in the documentation (regarding domain differences across sites), it looks like I have to use WSFC and create the availability groups in there to accomplish this? Any other way to accomplish this without more advanced configurations? From the instructions it looks like each site has a primary/standby pair, is that really required?Thursday, April 30, 2020 5:25 PM
Answers
-
Hi AllanChase99,
>>it looks like I have to use WSFC and create the availability groups in there to accomplish this?
Yes, WSFC is necessary. Without WSFC, it is not a High Availability solution, and you will lose things like automatic failover and database level health detection. Please refer to Prerequisites, Restrictions, and Recommendations for Always On availability groups.
>>From the instructions it looks like each site has a primary/standby pair, is that really required?
If you want to configure Distributed availability groups, then the condition that each site has a primary/secondary pair is required. You could try to create a domain-independent availability group which may meet the conditions you want. Please refer to Create a domain-independent availability group which might help.
Best Regards,
Amelia
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.- Proposed as answer by pituachMVP Friday, May 1, 2020 1:23 PM
- Marked as answer by AllanChase99 Friday, May 1, 2020 3:53 PM
Friday, May 1, 2020 9:20 AM
All replies
-
Hi AllanChase99,
>>it looks like I have to use WSFC and create the availability groups in there to accomplish this?
Yes, WSFC is necessary. Without WSFC, it is not a High Availability solution, and you will lose things like automatic failover and database level health detection. Please refer to Prerequisites, Restrictions, and Recommendations for Always On availability groups.
>>From the instructions it looks like each site has a primary/standby pair, is that really required?
If you want to configure Distributed availability groups, then the condition that each site has a primary/secondary pair is required. You could try to create a domain-independent availability group which may meet the conditions you want. Please refer to Create a domain-independent availability group which might help.
Best Regards,
Amelia
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.- Proposed as answer by pituachMVP Friday, May 1, 2020 1:23 PM
- Marked as answer by AllanChase99 Friday, May 1, 2020 3:53 PM
Friday, May 1, 2020 9:20 AM -
Hello,
You are unlucky.
In MS SQL Server 2016 cluster is required, so you need to be on same domain and you need to make a cluster on Windows server failover cluster manager as you said.
But in MS SQL Server 2017 you can make clusterless availability groups without the need of a domain or WSFC. The only limit is that you cant failover automatically and you have to make a force failover in case of the disaster.
I hope it helped.
- Proposed as answer by pituachMVP Friday, May 1, 2020 1:23 PM
Friday, May 1, 2020 9:26 AM -
Thanks Amelia, you have validated what I thought to be true and I appreciate that. I'll definitely need to go through the domain-independent group route and see how that goes. Thanks again.Friday, May 1, 2020 4:46 PM
-
Yeah, we really couldn't get to SQL Server 2017 because of other "constraints" on our program, so we had to go the 2016 route. It is good to hear that there is some flexibility for us in the future though. Thanks, I appreciate your thoughts.Friday, May 1, 2020 4:48 PM