/build/static/layout/Breadcrumb_cap_w.png

Migrate SQL 08 r2 cluster on win server 08 r2 cluster to SQL 14 on win Srv12 r2

Hi all;

I have a task of migrating a Multi-node SQL 08 r2 cluster on win server 08 r2 cluster to a Multi-node SQL 14 on win Srv12 r2 using the same storage.

Based on the research that I did so far, I concluded that I have to do the following:

1.  Install the Windows Server 2012 R2 operating system, required server roles and features, and any services or applications that will run on the new failover cluster

2. Prepare storage for the new cluster 

3. Create the new failover cluster and configure windows firewall 

4. Migrate the cluster roles – Use the Copy Cluster Roles Wizard in Failover Cluster Manager to migrate the cluster roles to the new cluster.

5. Verify the migration.

However; based on https://technet.microsoft.com/en-us/library/dn530781.aspx SQL Cluster Role can't be migrated! I'm confused...

Can you please guide me through the process, and detailed step by step guides are very welcomed.. 


0 Comments   [ + ] Show comments

Answers (1)

Posted by: h2opolo25 9 years ago
Red Belt
0
I would suggest you get a DBA for this.

1. What type of cluster do you have and what type of cluster are you going to? Shared Disks? Windows Clustering? AlwaysOn? etc...

2. There's some best practices here. Split database and log files between drives, format with 64k blocks, tempdb has it's own drive, swap has it's own drive, etc...

3.  Does the new cluster have to have the same name as the old? If so you will need to reset the AD object and things get tricky. Obviously this will kill the current SQL connections.

4-10 If at all possible clone your production environment in a dev environment and test with it. You might have to manually recreate users, Jobs, SSIS, Linked Servers, etc.... SQL creates the Windows Cluster service when it's installed as a cluster or AlwaysOn. If you just migrate the Windows Cluster, SQL will not go with it.

If you would like to take this endeavor by yourself I HIGHLY recommend spooling up a dev environment with clones of your DC, SQL Server Cluster, Application Servers that use SQL. Then TEST TEST TEST!

Comments:
  • Thank you for your reply, I will be handling the Windows Cluster part, and a DBA will handle the SQL part.

    I was thinking to do the following:

    1. Build 2 new servers with 2012 R2 OS and added them to the current Windows cluster which has 3 nodes.
    2. Have the DBA install and configure SQL for the new servers.
    3. Move the cluster to one of the new nodes.
    4. Evict the old servers upon shutting them down.
    5. Upgrade the old servers to Server 2012 R2 and SQL 2014.
    6. Bring the nodes back to the cluster.

    Does this work? - K9 9 years ago
    • Depends on your SQL Config. If you are using AlwaysOn then maybe it will. If you just have a SQL Cluster with shared drives then it probably won't work. There's so many variables when doing something like this that even the professionals request a dev environment before pulling the trigger in production. - h2opolo25 9 years ago
      • I totally agree. Only a fool would do this in a live environment. It's so simple to set up virtually these days, it's a no-brainer. - anonymous_9363 9 years ago
      • We have a test, Dev and Prod environments.. and the first migration will take place on the test environment that is a clone of the Prod environment.. btw, the clusters are physical clusters... not VMs.. I will lab it up on a virtual environment and will post any questions.. Thanks.. - K9 9 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ