August 5, 2013 at 8:59 am
Hi there,
I have the task of migrating two 2-node SQL 2008 R2 clusters on to new hardware. Currently the plan is to create new clusters from scratch, script all the logins, jobs, linked servers etc. and then just restore all the databases onto it. Finally I will alter the DNS name of the cluster to be the same as the existing one so I don't have to modify all the applications.
This will probably be fairly time consuming as there are a large number of databases on the servers.
Is this the best way to do it or could someone suggest a easier method?! ....or do I just need to stop whinging and get on with it? 😉
Thanks,
Matt
August 5, 2013 at 9:28 am
personally i would do it the way you have said, then you have a roll back position if required.
August 5, 2013 at 10:42 am
Depending on your SAN, you may be able to snapshot the drives rather than restore or swing the existing LUNs over to the new cluster. I couldn't give you a decent explanation on how to do it since I'm not a SAN guy (sorry). But I know I've seen it proposed.
August 5, 2013 at 10:56 am
Will the new hardware use the same version of windows as the existing cluster nodes?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 6, 2013 at 2:23 am
Thanks all for the responses...
Perry Whittle (8/5/2013)
Will the new hardware use the same version of windows as the existing cluster nodes?
There is a chance the new servers will have Windows Server 2012 rather than 2008 R2, however the SQL version will remain the same. Will this affect the migration process?
August 6, 2013 at 8:04 am
Once the new clusters are up you can also look at things like db mirroring or log shipping. That way the data is already replicating over to the new instances and you could reduce your cutover time.
Joie Andrew
"Since 1982"
August 6, 2013 at 8:34 am
Joie Andrew (8/6/2013)
Once the new clusters are up you can also look at things like db mirroring or log shipping. That way the data is already replicating over to the new instances and you could reduce your cutover time.
I'd not thought of doing it that way, although there are probably almost 200 databases to move, so I think setting up Mirroring for all of them could be rather arduous! I'll probably just write a script to restore them all I think....
August 6, 2013 at 10:11 am
matt.gyton (8/6/2013)
Thanks all for the responses...Perry Whittle (8/5/2013)
Will the new hardware use the same version of windows as the existing cluster nodes?There is a chance the new servers will have Windows Server 2012 rather than 2008 R2, however the SQL version will remain the same. Will this affect the migration process?
If all you were doing was moving to new hardware then its fairly easy.
Deploy the new servers and join them to the existing cluster then gradually migrate the old hardware out.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 7, 2013 at 4:37 am
Perry Whittle (8/6/2013)
matt.gyton (8/6/2013)
Thanks all for the responses...Perry Whittle (8/5/2013)
Will the new hardware use the same version of windows as the existing cluster nodes?There is a chance the new servers will have Windows Server 2012 rather than 2008 R2, however the SQL version will remain the same. Will this affect the migration process?
If all you were doing was moving to new hardware then its fairly easy.
Deploy the new servers and join them to the existing cluster then gradually migrate the old hardware out.
It's not just the servers that are being replaced it's the storage too, so I don't think that's an option?
Basically we are moving to a new secure datacentre which already contains the new hardware we'll be using, but the server admins couldn't find a way to migrate the RDMs from the current disks, so we figured creating a new cluster from scratch and migrating everything accross would be the easiest option.
August 14, 2013 at 12:27 pm
Have you thought of this method?
IF... and IF you install SQL Server to the exact same drives/paths on the current one, at cutover time stop SQL Server on the old cluster, then do a file copy of all of the .mdf .ndf .ldf files from the old server to the new server. Then start SQLServer and run the SP_DROPServer and SP_ADDSERVER to update the @@Servername within SQL Server to match the new server name and you would be good to go. The big benefit is that you won't have the backup/restore time. All you have is the file copy time. I have done this a couple of times when SQLServer version is the same. I just make sure the paths are exactly the same on install.
August 15, 2013 at 5:46 am
It's new hardware and a new cluster at a different location, so you're pretty much stuck having to do the busy work of moving each database whether via backup/restore of detach/attach.
There really isn't a way around the work. Hopefully you can move a few databases a day and not all 200 databases at once. You then have coordinate with the application(s) team to ensure they point and test the apps at the new server.
Steve
August 15, 2013 at 6:04 am
To shorten the cut-over time, you should create full backups (at least of the greater databases) and restore these on the new instance with norecovery. If you do this the day prior to the cut-over (or the same day), you only have to create and restore small differential backups. This can save you hours of downtime.
August 15, 2013 at 8:59 am
Did this with Win2003/SQL2000/SQL2005 cluster to Win2008R2/SQL2005/2008 cluster...
You can't really move # of databases at a time since they'll be on specific instances. You'd have to move an instance at a time (cluster group).
I did 1 instance/cluster group at a time. Get the new cluster up and running and move 1 cluster group at a time, make sure it's got the same resources defined. When ready to bring the new cluster group online, turn off the old group, rename the network name of the new group to match the original and bring the new group online. If drive letters/install path are different might have to do some updates to system database. I made sure that the drive letters and the install paths where all the same in the new cluster so I wouldn't have to update paths in the system databases. I did a backup and restore then took a diff backup and restore when bringing the new online. If something fails, turn off the new one and just turn the old one back on. Fix and repeat.
I migrated about 350 databases across 5 instances (cluster groups)...
Went from 2 CPU dual core servers with direct attached SAS storage to 2 CPU 8 core servers with Equalogic Fibre/SAS SAN...
---------------------------------------------------------------
Mike Hahn - MCSomething someday:-)
Right way to ask for help!!
http://www.sqlservercentral.com/articles/Best+Practices/61537/
I post so I can see my avatar :hehe:
I want a personal webpage 😎
I want to win the lotto 😀
I want a gf like Tiffa :w00t: Oh wait I'm married!:-D
August 15, 2013 at 9:21 am
Thanks for all the suggestions guys - interesting to see how people prefer to do it.
Think I have my plan sorted now. Fortunately I will have the new cluster ready in advance of the move, so I can spend as much time as necessary scripting everything accross, then I can simply write another script to restore all the databases (downtime is not too much of an issue, as we have the luxury of being able to take these services offline for a weekend without too much disruption).
Also, if I migrate a whole instance at once, I can keep the same DNS name for the cluster and not have to edit the applications 😉
Cheers,
Matt
October 15, 2016 at 12:03 am
Hi Markus,
We have a similar situation. Its a new build and we have to migrate clustered sql servers instances.
In old, sql server is 2005,2008 and 2012 and in new its 2014.
Below steps I was thinking:
1) Install sql server 2-node cluster in new servers
2) script everyhting from master and msdb like jobs,linked servers,credentials etc from source and run in new server
3) Over the SAN, drives would be copied. So, just attach the user databases in target
Would you like to add/remove in above steps?
Regards,
Yasir
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply