December 3, 2007 at 8:36 am
If I restore the master database from ServerA to ServerB and start the SQL Server services on ServerA and ServerB, the master databases will be identical and running sp_helpserver and @@ServerName will indicate the SQL Server instance for both instances is ServerA. Is this ok considering the physical server names are different?
If this is ok, how does SQL Server advertise on the network who it is? Does it append the physical server name to the SQL Server instance name during network communications?
Thanks, Dave
December 3, 2007 at 12:51 pm
For the most part it shouldn't be an issue - accessing the SQL Server is generally done via the machine name. However, there are a few things that rely on the SQL Server name matching the machine name (I forget exactly what). I consider it best practice to ensure the SQL Server name matches the machine name.
After restoring the master database to ServerB, you can rename the SQL Server as follows (run on ServerB):
sp_dropserver 'ServerA'
go
sp_addserver 'ServerB', 'local'
go
You will then need to restart SQL Server.
MARCUS. Why dost thou laugh? It fits not with this hour.
TITUS. Why, I have not another tear to shed;
--Titus Andronicus, William Shakespeare
December 3, 2007 at 1:15 pm
We just had a Disaster Recovery test that experienced some problems with servers using a real-time replication software called Double-Take. Several databases came up as suspect, possibly due to a new version of Double-Take. We want to run another test of Double-Take without having to cut the network link between our main office and the DR site. During a DR test we cut the link so to avoid having duplicate server names on the network, however in order to troubleshoot this latest issue we want to avoid cutting the link. For this reason I need to be certain we won't encounter any problems by having a production server and a DR server contain the same SQL Server instance name, but different physical server names. If behind the scenes SQL Server is using the IP address of the physical server and the port number of the SQL instance, then we will be ok.
Thanks, Dave
December 3, 2007 at 2:42 pm
Make sure that Doubletake can actually work with SQL Server. We have recently been doing a similar thing with Leostream. While Leostream apparently works with SQL Server (no special agents required it seems), in actual fact it doesn't (not for us, anyway) while SQL Server is running. The databases get corrupted. We can restore those. But something else gets corrupted, a DLL or something, and we get stack dumps every minute or so and most T-SQL commands won't run.
When we stop all SQL Server services, things seem to go a lot smoother. But of course, that defeats the goal of having a real-time updating DR system. :crazy:
MARCUS. Why dost thou laugh? It fits not with this hour.
TITUS. Why, I have not another tear to shed;
--Titus Andronicus, William Shakespeare
December 3, 2007 at 3:21 pm
"We just had a Disaster Recovery test that experienced some problems with servers using a real-time replication software called Double-Take. "
How interesting - I also had a DR test on Saturday using DoubleTake and it also failed with corrupt database files.
"Make sure that Doubletake can actually work with SQL Server."
In the past 18 months, I have had eight DR tests using DoubleTake and all eight failed - with 7 out of the 8 due to DoubleTake problems. One failed because an install of SP4 on the DR server failed but no one noticed (the SP install was done in November of 2004 and the next DR test was done in November of 2007).
If you using an SAN, SAN replication works very well, I have done dozens of DR tests this way and have had no problems with the data files or starting SQL Server.
"We want to run another test of Double-Take without having to cut the network link between our main office and the DR site."
Have you considered using DNS to route the requests to the appropriate server? That is, during a DR, have the production server name resolve to the IP of the DR server. This works flawlessly and no worries about duplicate server names on the network. You can also have both servers up at the same time so that patches can be applied to both simultaneously.
SQL = Scarcely Qualifies as a Language
December 4, 2007 at 7:40 am
We've been using Double-Take for a few years so I know it works well with SQL Server, however there is a possiblility the new version is not configured correctly. That's what we are investigating. We have a Microsoft engineer arriving tomorrow to assist us with a cluster configuration so I will pick his brain regarding how clients communicate with SQL Server. I suspect duplicate instance names are not a problem provided the physical server names are different. I'll provide an update later this week.
Thanks, Dave
January 14, 2010 at 9:38 am
I would really like to know how this works out as we are looking at Double Take for both HA and DR. Our original plan was to do mirroring with log shipping. Mirroring for HA and Log Shipping for DR. I was told there is this great new tool that would do all of this called Double Take. We have not set up Double take and as of now we are using log shipping for HA. Now we are adding a DR site with FIber and the plan seems to be to implement Double take. I would like to know if this is the answer and works or should we go back to our original plan of mirroring with log shipping. Thanks TA
January 15, 2010 at 8:21 am
I am also interested to know how this testing goes as well. We currently use Doubletake standard version 5.1 and have not had any issues with it. What version are you having issues with?
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply