October 9, 2018 at 6:45 pm
Hi,
I had a business case to migrate the existing SQL 2008R2 transactional replication subscriber DB to SQL server 2017 on IaaS in Azure.
The business wants to keep the current transactional replication subscriber on SQL 2008R2 parallel with new SQL 2017 on IaaS.
Current SQL2008R2 topology:
SQL1 : Publisher
SQL2 : Distributor and subscriber
Target mix SQL 2008R2 and SQL 2017:
SQL1 : Publisher
SQL2 : Distributor and subscriber
SQL3 : New SQL 2017 Distributor and subscriber
The goal is to keep both existing SQL2 (SQL2008R) and SQL 3 (SQL2017) subscribers running parallel.
Given, one publisher can only have one Distributor. I guess I have to break the existing replication between SQL 1 and SQL 2, and change the publisher from SQL1 to look SQL 3 distributor and recreate replication between SQL 2 and SQL 3.
Questions:
1. By BOL, it says,"A Subscriber to a transactional publication can be any version within two versions of the Publisher version." It sounds like it does not support subscriber on SQL 2017 while the publisher is on SQL 2008R2. However, I did a test on test servers, I am able to setup this up. I just wondering, is it firmly technically not supported by Microsoft or it is not recommended? What's the risk to setup this up.
2. Is there any other way better to achieve this?
3. what's steps to minimize down time if I need to break the existing SQL 2008 R2 replication and change over to the new SQL 2017 replication?
thanks and appreciated.
October 12, 2018 at 4:48 pm
mr.zl8888 - Tuesday, October 9, 2018 6:45 PMHi,
I had a business case to migrate the existing SQL 2008R2 transactional replication subscriber DB to SQL server 2017 on IaaS in Azure.The business wants to keep the current transactional replication subscriber on SQL 2008R2 parallel with new SQL 2017 on IaaS.
Current SQL2008R2 topology:
SQL1 : Publisher
SQL2 : Distributor and subscriberTarget mix SQL 2008R2 and SQL 2017:
SQL1 : Publisher
SQL2 : Distributor and subscriber
SQL3 : New SQL 2017 Distributor and subscriberThe goal is to keep both existing SQL2 (SQL2008R) and SQL 3 (SQL2017) subscribers running parallel.
Given, one publisher can only have one Distributor. I guess I have to break the existing replication between SQL 1 and SQL 2, and change the publisher from SQL1 to look SQL 3 distributor and recreate replication between SQL 2 and SQL 3.
Questions:
1. By BOL, it says,"A Subscriber to a transactional publication can be any version within two versions of the Publisher version." It sounds like it does not support subscriber on SQL 2017 while the publisher is on SQL 2008R2. However, I did a test on test servers, I am able to setup this up. I just wondering, is it firmly technically not supported by Microsoft or it is not recommended? What's the risk to setup this up.2. Is there any other way better to achieve this?
3. what's steps to minimize down time if I need to break the existing SQL 2008 R2 replication and change over to the new SQL 2017 replication?
thanks and appreciated.
You can usually bypass the replication restrictions if you are using t-sql. I think the wizards enforce the versions.
It's not supported. The risks would be if anything goes wrong, it's not supported. If it's short term just for comparison, that's would be one thing. If the business wants this long term for whatever reason, you probably need to rethink the versions being used or what they are trying to accomplish.
Sue
October 14, 2018 at 5:57 pm
thanks Sue, I did make the transactional replication working between SQL 2008R2 publisher with SQL2017 distributor and subscribers. I always uses script other than GUI, that's why I was confused in the firstly place, due to MSDN said the replication isn't supported.
Unfornately, the publisher DB has to stay on SQL 2008R2 as vendor doesn't support SQL2017 as yet. I will just let business know that, there may be some risks for this un-supported replication setup and push vendor to certify their product on a newer SQL version, so I can upgrade the publish DB.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply