Moving from Standalone to clustered SQL

  • Hi -

    We have a standalone SQL box that we need to migrate all the DBs to a new clusted environment that we will be building. The storage team with me detaching the existing storage desks from the standalone to the clusered servers so we do not move databases, just attach them back to the new clustered servers.

    The question I have is howto handle the system databases. From some links I see that others recommend restoring system databases, and then attaching the databases. Can you please tell me what is the best way is to handle the master database? Do you restore the master first, then do msdb and model DBs afterwards?

    The two new nodes we have need to be clustered? Is it better to first make the two nodes set as clustered and then have the storage team do the actual attachments to disks the day we go live?! What is the best way to set the clustered environment?

  • Do the right thing. Setup and build your Cluster from scratch. Then back up and restore your user databases, including msdb.

    Test IO with SQLIO before going live and of course, run Cluster Validation.

  • lsalih (5/10/2013)


    Hi -

    We have a standalone SQL box that we need to migrate all the DBs to a new clusted environment that we will be building. The storage team with me detaching the existing storage desks from the standalone to the clusered servers so we do not move databases, just attach them back to the new clustered servers.

    I once inherited an environment where this had been done before and i had to rebuild\install the cluster!

    There are various configuration items held in the system database and in the folder where the system databases reside, don't do it!!

    lsalih (5/10/2013)


    The question I have is howto handle the system databases. From some links I see that others recommend restoring system databases, and then attaching the databases. Can you please tell me what is the best way is to handle the master database? Do you restore the master first, then do msdb and model DBs afterwards?

    Don't move system databases between instances, especially standalone and clustered, script out any objects and apply them to the new system.

    lsalih (5/10/2013)


    The two new nodes we have need to be clustered? Is it better to first make the two nodes set as clustered and then have the storage team do the actual attachments to disks the day we go live?! What is the best way to set the clustered environment?

    Setup a new cluster with its own storage and move user databases across and script out any objects you require (jobs, users, etc).

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Many thanks to both of you... After doing further research, I agree with your input as I have seen where others had issues with restoring master database.

    Thanks,

    Lava

  • What if you do not restore system databases, just attach/detach storage? I mean make the current standalone storage shared with the clustered server, and just detach/attach storage once SQL clustering is setup?!

  • Sorry for the late reply... It is not recommended to just attach/detach storage. I ended up building the clustered server, and then doing bkup/rstr from the standalone. I ran into few security issues because some accounts had access to master and msdb which I forgot to do. It worked great.

  • Yeah, for all kinds of reasons, I'd never recommend detaching databases/volumes from a LUN from a SAN and just adding it to a cluster, there's so many issues that can arise from this and I wouldn't even think about doing the same with system databases. As others have suggested, build a fresh cluster from the start with dedicated shared storage etc, then backup and restore each database in turn, that way you can test each one while still keeping the original database online, and you have a rollback position of the original server\databases available in case there are issues with the cluster during configuration and testing.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply