How To: Migrate to AlwaysOn AlwaysOn from Prior Deployments Combining Database Mirroring and Log Shipping – Part 1

Writer: Cephas Lin (Microsoft)

Contributors: Oleg Bulanyy (Microsoft), Jimmy May (Microsoft)

This blog series is a follow-up to my whitepaper Migration Guide: Migrating to AlwaysOn Availability Groups from Prior Deployments Combining Database Mirroring and Log Shipping. In this series, I will walk you through the following end-to-end migration scenario inside a test environment:

• From a SQL Server 2008 R2 solution: Database mirroring for high availability and log shipping for disaster recovery
• To a SQL Server 2012 solution: Availability Group for both high availability and disaster recovery

Before I go further, l want to refer you to a whitepaper AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using AlwaysOn Availability Groups. This is a great architectural guide for anyone who is interested about the end-to-end deployment of the AlwaysOn scenario I'm discussing in this blog.

How to Use This Blog Series

This is a disclaimer similar to the one I have in How To: Migrate from Failover Cluster Instances and Database Mirroring to SQL Server AlwaysOn. My walkthrough steps are to help people get started on implementing a end-to-end migration scenario in a test environment. I have already published prescriptive guidance on the migration scenario in Migration Guide: Migrating to AlwaysOn Availability Groups from Prior Deployments Combining Database Mirroring and Log Shipping. If you are a database architect seeking guidance on migrating your production system to SQL Server AlwaysOn, I advise you to look there first. If you are a database administrator who needs help to get started on migrating your company's database system to SQL Server AlwaysOn, then my blog is for you. To expedite the testing phase of you migration scenario, I recommend that you walk through the entirety of this blog series, which can help you recognize and avoid many issues that can trip you up along the way. Once you have successfully completed the walkthrough in your test environment, you will know what success looks for a generalized scenario. The next natural step continue the testing phase with the specification of your SQL Server deployment.

I cannot emphasize enough: DO NOT apply these migration steps blindly to your production system. To minimize the risks of your actual migration to SQL Server AlwaysOn, test these steps thoroughly against every aspect of your SQL Server deployment (I repeat, in a test environment) and incorporate all the necessary tweaks to accommodate your specific scenario.

Migration Walkthrough Overview

You will walk through the migration procedures as covered in Migration Guide: Migrating to AlwaysOn Availability Groups from Prior Deployments Combining Database Mirroring and Log Shipping Par I – Prescriptive Guidance.

The following table outlines the starting point and the end point of the walkthrough.

The four stages of migration as covered in the whitepaper are as follows:

1. Online upgrade of the log shipping secondary database server (REMOTE1).
2. Online upgrade of the mirror database server (PRIMARY2).
3. Online upgrade of the principal database server (PRIMARY1).
4. Configuration of an availability group.

If you build the base configuration I prescribe here, you will find a clear path to success in the migration procedure. You can instead use your existing HADR solution as the base configuration, but just realize that I cannot guarantee that my migration steps will work as-is with your HADR solution. In all likelihood, you will need to tweaks as you follow along. Make sure that you test the migration steps thoroughly before attempting the same steps on your production environment.

As client connectivity is an important part of the migration scenario, you will simulate a client workload on the database system to test the HADR capabilities of the system before, during, and after the migration process. In addition, the client workload is used to demonstrate how to configure client applications to work with AlwaysOn Availability Groups.

Industry Best Practices

You should observe all industry best practices in the implementation of your HADR system in general. For example, network redundancy is crucial for a production environment to circumvent outages due to network anomalies. You may notice that I simplify such elements especially in some screenshots, so that they don't become a distraction from the migration steps themselves.

Success Criteria    

This walkthrough attempts to balance between a real-life migration environment and requirements and the generalized use case. While it does not possess the complexity of a real-life scenario, a few common migration criteria are included.

• Maintain separation of roles, where applicable (domain administrator, database administrator, application developer).
• Minimize downtime during migration.
• Approximate the high availability and disaster recovery capabilities during migration.

Prerequisites

To prepare the base configuration, you need the following hardware and/or software:

• Hardware to implement the network topology, including servers, switches, and so on. You can simulate the network topology using Hyper-V.
• Windows Server 2008 R2
• SQL Server 2008 R2 SP1 (see note below)
• Visual Studio
• Windows 7

To complete the migration process successfully, you need the following additional software:

• SQL Server 2012 (see note below)
• KB 2494036

NOTE: For more information on all supported version upgrades, see Supported Version and Edition Upgrades. The in-place upgrade described in this blog series does not support upgrade paths from or to Evaluation Editions of SQL Server. Furthermore, you must use an edition of SQL Server that supports database mirroring, log shipping, and AlwaysOn Availability Groups where applicable. The minimum license requirement for completing the walkthrough is summarized below.

For more information, see Features Supported by the Editions of SQL Server 2012.

Step 0: Setup Base Configuration

So, let's start!

First, you implement the network topology shown in the diagram below. The two subnets simulate the two sites in Contoso Corporation. The client machine simulates a write workload on the SQL Server instances during the migration process.

The walkthrough steps focus on the software configuration on the server nodes and not on the implementation of the network topology.

Set up the Domain Controller and Accounts

Role: Domain Administrator

1. Set up the domain controller(DC) for DNS service with the domain specifications below.

   Domain Name	CORP
   FQDN	corp.contoso.com

2. Create the domain user accounts show below:

   Domain Administrator	CORP\Administrator
   SQL Installation	CORP\Install
   Database Administrator	CORP\DBAdmin
   Client Application	CORP\SQLClient
   SQL Service Accounts	CORP\SQLSvc1 CORP\SQLSvc2 CORP\SQLSvc3 CORP\SQLSvc4 CORP\SQLAgent1 CORP\SQLAgent2 CORP\SQLAgent3 CORP\SQLAgent4

Deploy SQL Server 2008 R2 Solution

Role: Database Administrator

Perform the following steps on PRIMARY1, PRIMARY2, WITNESS, and REMOTE1:

1. Install Windows Server 2008 R2 SP1, and then join the machine to the domain.

2. Give CORP\Install administrative privileges on the local machine.

3. Install the default SQL Server 2008 R2 instance with the respective service accounts shown below.

   Machine	SQL Service Account	SQL Agent Account
   PRIMARY1	SQLSvc1	SQLAgent1
   PRIMARY2	SQLSvc2	SQLAgent2
   WITNESS	SQLSvc3	SQLAgent3
   REMOTE1	SQLSvc4	SQLAgent4

4. Open the firewall for remote access of the default SQL Server instance with the following command:

   netsh advfirewall firewall add rule name='SQL Server (TCP-In)' dir=in action=allow protocol=TCP localport=1433 profile=domain

5. In SQL Server Configuration Manager, under the SQL Server Network Configuration node, enable the TCP/IP protocol.

6. Restart the database instance.

Create Databases and Configure Database Mirroring

Role: Database Administrator

Perform the following steps to create the databases and configure database mirroring sessions.

1. On both PRIMARY1 and PRIMARY2, open port 5022, the default port SQL Server uses for database mirroring with the following command:

   netsh advfirewall firewall add rule name='SQL Server Mirroring (TCP-In)' dir=in action=allow protocol=TCP localport=5022 profile=domain

2. In SQL Server Management Studio (SSMS), create two databases on PRIMARY1, named test1 and test2.

3. Create a table in both test1 and test2, called table1, using the following script:

   CREATE TABLE dbo.table1(col1 nchar(10), col2 nchar(10))

4. Prepare the mirror databases for test1 and test2 on PRIMARY2.

5. Establish the database mirroring sessions on the two databases using the specifications below.

   Principal Role	PRIMARY1
   Principal Service Account	CORP\SQLSvc1
   Principal Endpoint	TCP://primary1.corp.contoso.local:5022
   Mirror Role	PRIMARY2
   Mirror Service Account	CORP\SQLSvc2
   Mirror Endpoint	TCP://primary2.corp.contoso.local:5022
   Witness Role	WITNESS
   Witness Service Account	CORP\SQLSvc3
   Witness Endpoint	TCP://witness.corp.contoso.local:5022
   Operating Mode	High safety

After you configure database mirroring on table1 and table2, you can use the Database Mirroring Monitor to make sure that the servers have connectivity and are synchronized for both databases. It should look similar to the screenshot below.

Configure Log Shipping

Role: Database Administrator

Perform the following steps to set up log shipping for the two databases.

1. On PRIMARY1, PRIMARY2, and REMOTE1, in SQL Server Configuration Manager, set the SQL Server Agent service to start automatically.

2. Start the SQL Server Agent service on all three machines.

3. Create the following share folders:

   Network Name	Permissions
   \\WITNESS\test1 \\WITNESS\test2	SQLSvc1: Read and Write SQLSvc2: Read and Write SQLSvc4: Read SQLAgent4: Read
   \\REMOTE1\test1 \\REMOTE1\test2	SQLSvc4: Read SQLAgent4: Read and Write

4. On PRIMARY1 and PRIMARY2, set up log shipping of test1 and test2 to REMOTE1 using the following parameters:

   Database	Backup Folder	Destination Folder for Copied Files	Restore Mode
   test1	\\WITNESS\test1	\\REMOTE1\test1	No recovery
   test2	\\WITNESS\test2	\\REMOTE1\test2	No recovery

NOTE: Since you are mixing database mirroring and log shipping, you cannot perform this step using the SSMS user interface alone. For instructions, see the Log Shipping to a Third Destination from a Database Mirroring Pair section in Database Mirroring and Log Shipping Working Together.

When you are finished, the SSMS view of the three database instances in Object Explorer should look similar to the screenshot below. PRIMARY1 is the principal database server for both databases and PRIMARY2 is the mirror database server.

Configure Access for the Client Application

Role: Database Administrator

For client access to the databases, perform the following steps in SSMS for the various database instances:

1. On PRIMARY1, add CORP\SQLClient as a login, and then give CORP\SQLClient the following database memberships for both test1 and test2:
   • db_datareader
   • db_datawriter
2. Perform a manual database mirroring failover for both test1 and test2 to PRIMARY2.
3. In PRIMARY2, add CORP\SQLClient as a login, and then give CORP\SQLClient the following database memberships for both test1 and test2:
   • db_datareader
   • db_datawriter
4. Perform a manual database mirroring failover back to PRIMARY1.

You will use CORP\SQLClient to connect to the databases from the client application in later steps. If a failure happens during your migration process, you have ensured that clients have access to the automatic failover partner. In a disaster recovery scenario, you must bring REMOTE1 online, and then add CORP\SQLClient to REMOTE1, and then configure the same database memberships so that client applications can connect to it.

Role: Application Developer

On CLIENT, perform the following steps to run the client application.

1. Install Windows 7.

2. Join the machine to the corp.contoso.com domain using the CORP\Administrator account.

3. Logout and login as CORP\Install.

4. Install SQL Server 2008 R2 Management Studio.

5. Start SSMS and connect to PRIMARY1 and PRIMARY2 to verify that the database instances can accept remote connections.

6. Install Visual Studio.

7. Logout and login as CORP\SQLClient.

8. Create a console application (named ConsoleApplication1 by default), and then replace the code in Program.cs with the code below. This code continually attempts to connect to test1 and insert a record. Each connection attempt has three retries and a 5-second interval between each retry. The connection logic is taken from Implementing Application Failover with Database Mirroring.

   using System;

   using System.Data;

   using System.Data.SqlClient;

   using System.Threading;

    

   namespace ConsoleApplication1

   {

     class Program

     {

       const string connString = @"Server=PRIMARY1;Failover Partner=PRIMARY2;Initial Catalog=test1;Integrated Security=True";

    

       static bool ExecuteSQLWithRetry_NoResults(string strConn, string strCmd, int iRetryInterval, int iMaxRetries)

       {

         SqlConnection conn = null;

         SqlCommand cmd = null;

    

         for (int iRetryCount = 0; iRetryCount < iMaxRetries; iRetryCount++)

         {

           try

           {

             conn = new SqlConnection(strConn);

             conn.Open();

             if (null != conn && ConnectionState.Open == conn.State)

             {

               cmd = new SqlCommand(strCmd, conn);

               cmd.ExecuteNonQuery();

               return true;

             }

           }

           catch (Exception ex) { }

           finally

           {

             try

             {

               if (null != cmd)

                 cmd.Dispose();

               if (null != conn && ConnectionState.Closed != conn.State)

                 conn.Close();

             }

             catch (Exception ex) { }

           }

    

           if (iRetryCount < iMaxRetries)

             Thread.Sleep(iRetryInterval * 1000);

         }

    

         return false;

       }

    

       static void Main(string[] args)

       {

    

         while (true)

         {

           Random rand = new Random();

           string cmdString = "Insert into table1 values (N'" + rand.Next() + "',N'" + rand.Next() + "')";

    

           if (ExecuteSQLWithRetry_NoResults(connString, cmdString, 5, 3))

             Console.WriteLine("Success: " + cmdString);

           else Console.WriteLine("Error: " + cmdString);

         }

       }

     }

   }

9. Run the application by opening the Debug menu and clicking Start Debugging.

You have now finished setting up the base configuration and are ready to start the migration scenario to the SQL Server AlwaysOn solution in SQL Server 2012.

But wait, this blog has gotten too long already! In the next installment, you will actually start the migration steps. Stay tuned!

Comments

• Anonymous
  December 14, 2012
  The comment has been removed

• Anonymous
  June 19, 2014
  I work for SAP Education and came across this blog the other day. Many thanks for  highlighting SAP Learning Hub in such a positive manner! The elements of services, tools and documentation form the basis for successfully executing the migration. The tools support the R3load procedure. <a href="saptrainings.com/.../">SAP OS DB MIGRATION ONLINE TRAINING</a>

• Anonymous
  July 02, 2014
  there is plenty more that is covered by a sap training module. You could even choose areas of specialization depending on your requirement. The SAP OS DB MIGRATION ONLINE TRAINING is mandatory if you are going to migrate a productive system. The service delivery then includes all the systems in that system landscape. <a href="saptrainings.com/.../">SAP OS DB MIGRATION ONLINE TRAINING</a>

• Anonymous
  July 02, 2014
  SAP OS DB MIGRATION ONLINE TRAINING complete Support for a Migration of your Operating System and Database Description ,If at any stage of the SAP software life cycle you should need to change your operating system and/or database, the SAP OS DB MIGRATION ONLINE TRAINING Check optimally prepares you for a successful migration and supports smooth continued operations on the new platform. The SAP OS DB MIGRATION ONLINE TRAINING is mandatory if you are going to migrate a productive system. The service delivery then includes all the systems in that system landscape. If you want full support for the migration (be it a production system or not) then you must secure the services of a technical consultant with special certification for OS/DB migration. <a href="saptrainings.com/.../">SAP OS DB MIGRATION ONLINE TRAINING</a>