May 31, 2018 at 2:54 pm
Hi, we want to start using availability groups for Disaster Recovery solution in remote Data Center. (instead of a database mirror) We are running W2016 and SQL2017
Locally we are using a Failover cluster instance. In remote Data Center we have a single server instance. My understanding is dat all Alwayson availability group replication nodes have to be part of the same windows cluster. Is this true? When adding the DR Windows server to the existing SQL failover cluster and installing SQL Server we get issue with using same drive letters. Although we have removed access for remote server to the clustered storage, we cannot local drives with same drive letter. We want to use the same drive letters as this is best practice for a good reason. Can we solve this in the windows cluster? Or can we create a 2nd cluster in remote DC with single instance and create a availability group between clustered local instance and remote single SQL server instance? Any information on this is appreciated. Thanks.
May 31, 2018 at 3:41 pm
Evict the DR node from the cluster - and verify the storage is available. Install SQL Server exactly the same as you performed on the FCI nodes - that is, the same drives/paths for system files, user database, transaction logs and tempdb.
Once you have SQL Server installed and patched to the same level as the FCI instance - then add the node back into the cluster. At that point - you can setup the availability group and start adding databases.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 2, 2018 at 6:08 am
Hi Jeffrey, thanks for response. Indeed this works. Too bad we can still not use the remote server for AG. We are able to add remote server to Windows Cluster, we have 3 nodes. 2 local, 1 remote. But when creating AG and adding the remote server as secondary we get error message that remote server is either not part of the cluster or that user does not have sysadmin permissions to get cluster information. We use same service account on all instances, our accounts are sysadmin on all instances. Not sure what is causing this issue. If you have any idea, let me know.
thanks,
Roy
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply