Upgrading a Replication Topology to SQL Server 2016

SQL Server Replication provides multi-faceted data movement capabilities across SQL Server releases which has been used by customers across the globe for a large number of years. When moving from one major release of SQL Server to another, replication topology upgrade has been a constant topic of lengthy discussions. In this post, we shall outline some of the challenges of upgrading SQL Server replication environments to SQL Server 2016. The requirements of upgrading a replication topology need to abide by the following guidelines:

• A Distributor can be any version as long as it is greater than or equal to the Publisher version (in many cases the Distributor is the same instance as the Publisher).
• A Publisher can be any version as long as it less than or equal to the Distributor version.
• Subscriber version depends on the type of publication:
  • A Subscriber to a transactional publication can be any version within two versions (n-2) of the Publisher version. For example: a SQL Server 2012 Publisher can have SQL Server 2014 and SQL Server 2016 Subscribers; and a SQL Server 2016 Publisher can have SQL Server 2014 and SQL Server 2012 Subscribers.
  • A Subscriber to a merge publication can be any version less than or equal to the Publisher version.

If you had to draw a support matrix for the major release versions for transactional and merge replication, the output would be the two tables shown below.

Transactional Replication Matrix

Merge Replication Support Matrix

If you notice the line items for SQL Server 2016, you will see that a topology is unable to support SQL Server 2016 in a number of scenarios when you are running SQL Server 2016 as a publisher. Replication topologies have three common deployment patterns as shown in the visio diagram below. The distributor could be on the publisher or subscriber or a remote distributor. We do come across different deployments of the publisher and subscriber which are a mix of standalone instances, SQL Server failover cluster instances or Always On Availability Group replica instances.

Depending on the deployment pattern, the upgrade path to SQL Server 2016 would be different. Let us explore the different possibilities. SQL Server offers two upgrade paths in general:

• Side-by-side: This approach involves setting up a new parallel environment and moving the databases along with the associated instance level objects like logins, jobs etc. to the new environment.
• In-place upgrade: With this approach, the SQL Server setup program upgrades the existing SQL Server installation by replacing the existing SQL Server bits with the SQL Server 2016 bits and then upgrades each of the system and user databases. For environments running SQL Server failover cluster instances or Always On Availability Groups, an in-place upgrade is combined with a rolling upgrade to minimize downtime.

The scenarios below apply to Transactional Replication (without P2P Replication, Queued Updating Subscription and Immediate Updating Subscription) and Merge Replication. The options below outline how a phased approach can be adopted for your replication topology upgrade so that you don't have to upgrade all the SQL Server instances in one big upgrade operation.

A common approach that has been adopted for side-by-side upgrades of replication topologies is to move publisher-subscriber pairs in parts to the new side-by-side environment as opposed to a movement of the entire topology. This phased approach helps to control downtime and minimize the impact to a certain extent for the businesses dependent on replication.

Upgrading a Replication Topology with a Remote Distributor

*See "Side-by-side Upgrade of the Distributor without re-initialization" below

*See "Side-by-side Upgrade of the Distributor without re-initialization" below

Upgrading a Replication Topology with Publisher acting as the Distributor

*See "Side-by-side Upgrade of the Distributor without re-initialization" below

*See "Side-by-side Upgrade of the Distributor without re-initialization" below

Upgrading a Replication Topology with Subscriber acting as the Distributor

*See "Side-by-side Upgrade of the Distributor without re-initialization" below

*See "Side-by-side Upgrade of the Distributor without re-initialization" below

Side-by-side Upgrade of the Distributor without re-initialization

If you are running your SQL Server instance to be upgraded on Windows Server 2008 or Windows Server 2008 R2, then you will need to perform a side-by-side upgrade of the distributor first to Windows Server 2012 R2 or Windows Server 2016 before upgrading to SQL Server 2016. The reason for this intermediate OS upgrade is that SQL Server 2016 cannot be installed on a Windows Server 2008/2008 R2 server. The side-by-side approach can also help reduce downtime if you are upgrading the hardware of the Windows Server hosting the distributor instance. Downtime of the publisher and subscriber can be reduced using SQL Server Failover Cluster instances or Always On Availability Groups.

The assumption here is that the edition of the SQL Server instance will not change and a failover cluster instance of SQL Server will be upgraded to a failover cluster instance where as a standalone instance will be upgraded to a standalone instance using the steps mentioned below.

Steps for side-by-side migration of the distributor to Windows Server 2012 R2

• Setup a new failover cluster or standalone instance running the same major release, edition and version as your distributor on Windows Server 2012 R2/2016 with a different windows cluster and SQL Server FCI name or standalone host name. You will need to keep the directory structure same as the old distributor to ensure that the replication agents executables, replication folders and database file paths are found at the same path on the new environment. This will reduce any post migration/upgrade steps required.
• Make sure that the current synchronization is complete and post that shut down all the replication agents
• Shut down the current SQL Server failover cluster instance or standalone instance running as the distributor. If this is a standalone instance of SQL Server, you will need to shutdown the Windows Server hosting  the SQL Server instance to ensure that there is no conflict while renaming the server.
• Remove the DNS entries for the old (current distributor instance) environment and the AD entries for the computer object for the SQL Server FCI
• If this is a SQL Server Failover Cluster instance, rename the new SQL Server Failover Cluster instance name with the old virtual server name. If this is a standalone SQL Server instance, then rename the new standalone host with the old hostname.
• Copy the database files from the previous instance using SAN redirection or storage copy or file copy
• Bring the new SQL Server instance online
• Restart all the replication agents and verify if the agents are running successfully
• Validate if replication is working as expected

In-place upgrade to SQL Server 2016

• Run in-place upgrade for SQL Server 2016 on the new cluster
• If required, rebuild old nodes and add to the cluster to re-use existing hardware
• Validate if replication is working fine

If you want to reduce the downtime, we recommend that you perform the side-by-side migration of the distributor as one activity and the in-place upgrade to SQL Server 2016 as another activity. This will allow you to take a phased approach, reduce risk and minimize downtime.

Summary

Upgrading a replication topology is a multi-step process. We recommend attempting an upgrade of a replica of your replication topology in a test environment before running the upgrade on the actual production environment. This will help iron out any operational documentation that is required for handling the upgrade smoothly without incurring expensive and long downtimes during the actual upgrade process. We have seen customers reduce downtime significantly with the use of Always On Availability Groups and/or SQL Server Failover Cluster Instances for their production environments while upgrading their replication topology. Additionally, we recommend taking backups of all the databases including MSDB, Master, Distribution database(s) and the user databases participating in replication before attempting the upgrade.

Resources

Recovering a Deleted Cluster Name Object (CNO) in a Windows Server 2008 Failover Cluster Upgrade Replicated Databases Supported Version and Edition Upgrades for SQL Server 2016 Hardware and Software Requirements for SQL Server 2016 SQL Server Upgrade Rename a Computer that hosts a Standalone instance of SQL Server Rename a SQL Server Virtual Server Name

Comments

• Anonymous
  February 02, 2017
  Amit,your overview of transactional replication does not match the documentation and testing shows a different behavour.It is possible use a transaction replication from SQL 2008R2 to SQL 2016 using SQL 2008R2 as publisher and distributor.the documentation for SQL 20016 Replication https://msdn.microsoft.com/en-us/library/ms143550.aspx says that support for SQL 2008R2 replication is deprecated but still supported.
  • Anonymous
    February 02, 2017
    Publisher and subscriber pairs with SQL Server 2008/R2 - SQL Server 2016 combinations are not allowed. The matrix shows that you can use SQL Server 2016 when it's a remote distributor (transaction replication) and this can be used as an interim measure for an upgrade to SQL Server 2016.
    • Anonymous
      February 02, 2017
      "Publisher and subscriber pairs with SQL Server 2008/R2 – SQL Server 2016 combinations are not allowed."the GUI in SSMS allows to subscribe SQL 2016 to a SQL 2008R2 publication and modification on SQL 2008R2 are replicated to SQL 2016 correctly as far as I've seen in my testing.
      • Anonymous
        February 02, 2017
        We allow it through scripts and SSMS. We don't support a publisher-subscriber pair which is older than n-2. In other words, Microsoft Support will not provide support for such a configuration. We don't block it from the UI/T-SQL scripts.
• Anonymous
  February 05, 2017
  Hello Amit,in this atricle you assumed that the SQL-Edition on the Publisher & Distributor would not be downgraded (e.g. Enterprise to Standard) during the side-by-side migration. What would be the approach in the downgrade case ? Using the restore option with keep_replication ?Best Regards,Bobi
  • Anonymous
    February 05, 2017
    If the edition that is being downgraded does not support the replication feature that you are using, then you will need to restore the database without KEEP_REPLICATION option. If you are restoring the database and need to keep the replication settings, then you need to use KEEP_REPLICATION. The situation where a side-by-side migration would require restoring databases is outlined in the section "Side-by-side Upgrade of the Distributor without re-initialization". If you are setting up replication all over again, then you shouldn't use the KEEP_REPLICATION option.
    • Anonymous
      February 06, 2017
      Thanks for your fast response!By the step "Copy the database files from the previous instance using SAN redirection or storage copy or file copy" I understood a simple copy of the database files. I'm not sure, if the SQL-Server would start, when the master database e.g. from the enterprise edition replaces the master database on the new one e.g. standard edition. ASAIK Microsoft doesn't support Enterprise downgrade. In my opinion, because of the different SQL editions, I can't restore the master database in a downgrade scenario, but I need to do it in order to avoid the re-initilization of the replication. Therefore, either the SQL edition must not be changed or a complete re-initialization is required. Could you please share your opinion for this situation ?Best Regards,Bobi
      • Anonymous
        February 06, 2017
        The comment has been removed
        • Anonymous
          February 08, 2017
          Thanks for your feedback
      • Anonymous
        February 06, 2017
        I would recommend working with Microsoft Premier Services to design an upgrade path for your environment to help minimize downtime and also in a supported manner.
• Anonymous
  February 07, 2017
  I am actually doing my production upgrade tomorrow morning. Already completed in DEV, QA and UAT. Key take away is to ensure you install 2016 SP1 as well.
• Anonymous
  February 14, 2017
  Hi AmitWe have a problem - we need to temporarily replicate a SQL 2000 server database by transaction to SQL 2016 in real or near real time. The tables indicate that this is not directly possible. The path would require 3 hops, 0-8, 8-12 and 12-16 which is not doable. Any ideas?Thanks
  • Anonymous
    February 16, 2017
    Unfortunately, there is no upgrade path using replication from SQL Server 2000. Have you tried scripted backup and restore using an intermediate version?
• Anonymous
  March 13, 2017
  We have a replication environment where the subscriber has legacy data that cannot be reinitialized from publisher. This is on 2008 R2. Can we do the following based on this article :a. Setup new distributor server with Windows 2012 R2 and SQL 2008 R2 (same as before SQL version). Then migrate the distributor and other system databases to the new server. (rename the new server to old.. )b. Bring up the new distributor server and test the replication works fine. c. Upgrade the new distributor server with in place upgrade to 2014 SP1. Once again make sure replication continues to work.d. Then setup new 2014 server (same name as before) for publisher and migrate the application databases, jobs, users, logins etc (excluding system dbs).e. Repeat step d. for the subscriber as well.Any reason this wont work ?
  • Anonymous
    March 24, 2017
    The above should work and you will need to test it before you implement that on production.