January 27, 2023 at 9:07 pm
can you please provide your feedback on following scenario.
i am migrating a database server (Active/passive) cluster to Alwayson (2019). issue is the server name is used in connection strings over 200 machines. i need to retain the server name otherwise based on vendor each workstation software has to reinstalled/reconfigured with servername.
old name is SINSTANCE12345\INST1
old virtual instance is over 15 characters AD team cannot create same name for alwayson listener.
CName cannot have backslash.
CName or AD team can retain this SINSTANCE12345
what are other possible solutions in the case.
January 28, 2023 at 9:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
January 29, 2023 at 6:07 pm
I would take the time to reinstall/reconfigure the workstations - using a CNAME alias instead of the actual server name. In the future when you have to perform another upgrade or migration it will simply be an update to that CNAME to point to the new server.
Migrating from an FCI to a AG cluster - you are going to have to update the connection strings anyways. You need to reference the listener in the AG and not a specific server or instance. Once you setup the listener - then create a CNAME alias to the listener IP address, and again - when you upgrade/migrate in the future the cutover is a simple DNS update.
To be honest, it doesn't make sense that you are referencing an instance name in an FCI cluster anyways. You should be accessing that FCI cluster using the SQL Server cluster name which wouldn't have a slash or instance specified.
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
February 3, 2023 at 4:20 pm
Building on what Jeffrey says... You can have the new alias set up in AD prior to the migration pointed at the existing cluster. That gives you time to migrate the clients to using the alias ahead of time. On migration day the only reconfiguration for the workstations would be to repoint the alias to the new environment. It requires work, but avoids extended downtime and as an added bonus provides an easy route to fail them back in case of complications.
February 4, 2023 at 12:18 pm
I totally agree with the previous two posts suggesting you reconfigure the workstations to use a DNS alias. It will be painful but it will make future migrations much easier.
As a matter of principal I always look to put in a layer of indirection wherever possible. This means DBS aliases in connection strings and always building DB servers as Hyper-v (or other) guests. It all helps make the environment easier to upgrade when the time comes.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply