September 20, 2017 at 3:00 am
Hi all
I am setting up an AlwaysOn AG in asynch mode to create a DR replica for an existing Production SQL Server. There is already a DNS alias in place to reference the prod server, which is referenced from different systems in multiple config files, data sources, connection strings. When creating the listener, I will have to choose a unique name (different to the current alias) as you cannot have duplicate aliases on the network. As we are using asynchronous mode (manual failover) I am assuming we don't need to use the listener but can carry on using the existing DNS alias to reference the server and just update the alias to point to the AG replica server in a DR scenario? I don't want the Devs to have to go through the trouble of updating all references to the prod server to use the new listener name, if it can be avoided.
Thanks in advance!
September 20, 2017 at 3:35 am
You don't have to use a listener at all, but in your scenario I'd change the DNS entry so that the alias points to the listener anyway. Then if you do have to fail over to the other replica, you won't have to update anything.
September 20, 2017 at 3:35 am
doodlingdba - Wednesday, September 20, 2017 3:00 AMWhen creating the listener, I will have to choose a unique name (different to the current alias) as you cannot have duplicate aliases on the network.
Delete the alias first then pre stage the VCO and dns host record. Once this is done create the listener specifying the dns name
doodlingdba - Wednesday, September 20, 2017 3:00 AM
As we are using asynchronous mode (manual failover) I am assuming we don't need to use the listener but can carry on using the existing DNS alias to reference the server and just update the alias to point to the AG replica server in a DR scenario?
The listener is employed mnainly to direct read intent connections, if you don't plan to use read only routing then you may not need a listener
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 20, 2017 at 4:26 am
Beatrix - that sounds like a great plan! I hadn't thought of that. Thanks for the advice 🙂
September 20, 2017 at 4:30 am
Thanks Perry! Unfortunately I can't delete the alias because deleting the alias would bring down the production system! So many things point to the alias. I get what you are saying about read-intent connections but we wont be using those, at least not for now.
Beatrix' suggestion of getting the existing alias to point to the listener instead of the server sounds like the perfect solution for my case because it means no one has to update anything on failover.
September 20, 2017 at 4:37 am
doodlingdba - Wednesday, September 20, 2017 4:30 AMThanks Perry! Unfortunately I can't delete the alias because deleting the alias would bring down the production system! So many things point to the alias. I get what you are saying about read-intent connections but we wont be using those, at least not for now.
Beatrix' suggestion of getting the existing alias to point to the listener instead of the server sounds like the perfect solution for my case because it means no one has to update anything on failover.
you must surely have a maintenance window where you could perform the task, either that or just point existing alias, it's a little untidy though, not ideal
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 20, 2017 at 4:59 am
Hi Perry - i've just realised what you are saying - sorry. So you mean use the same name for the listener as the existing alias - but just delete the alias first during a maintenance window, then configure the listener.... so no need to update any config files. Yes this would work! The whole point is to avoid having to changing the numerous config files and connection strings to point to a new alias. I think I thought briefly of this but discounted it early on as i wanted to avoid downtime during the AlwaysOn set up but... it is a neater solution then pointing aliases at aliases.....
September 20, 2017 at 5:11 am
doodlingdba - Wednesday, September 20, 2017 4:59 AMHi Perry - i've just realised what you are saying - sorry. So you mean use the same name for the listener as the existing alias - but just delete the alias first during a maintenance window, then configure the listener.... so no need to update any config files. Yes this would work!
yes, that is what i'm saying 😉
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply