Recommended distributor architecture for transactional replication?

Question

We are planning to create a Transactional replication on 2 nodes of SQL Server 2008 R2, each node will be a publisher and a subscriber.

What is the best practice in order to have this scenario done? Microsoft always recommends that the distributor should be independent from the publisher or the subscriber, so it is obvious that a 3rd node is to be involved in the scenario. But, as each node will be at the same time publisher and subscriber, can the same (3rd node) be the distributor for the 2 publishers? Should I create 2 distributors, or can it still be on the same architecture, using only 2 nodes, each one acting as distributor as well as publisher?

Answer 1

What is the best practice in order to have this scenario done?

It depends on how much data you are replicating i.e.

• Are you replicating selected columns/tables, entire database (all tables), etc ?
• Are both nodes located in the same domain or different domains ?
• Are you replicating in same region or cross region (US-UK, etc) ?

I have implemented T-Rep where I have used same server as publisher and distributor as the data that was needed to replicate was less and also, have implemented separate distribution database on separate server that does all the heavy lifting of publishing the data to subscribers where we had massive data to push down to subscribers.

You have to consider factors like -

• time taken to perform snapshot and applying that snapshot to subscribers
• Feasibility of re-initializing the articles when a major (e.g. schema) change occurs to the tables that are involved in replication.

should I create 2 distributors? You can use the same distribution database. Though, for ease of maintenance and better performance [reducing contention - both writing to and reading from the distribution database] I would highly recommend you use separate Distribution databases.

Remember that distribution database is the heart of replication. So it requires proper maintenance, backups, etc. Now if you have just 1 distribution database that supports multiple publishers and a DISASTER happened, then restoring it from a previous backup will impact ALL publishers.

From BOL :

In many cases, a single distribution database is sufficient. However, if multiple Publishers use a single Distributor, consider creating a distribution database for each Publisher. Doing so ensures that the data flowing through each distribution database is distinct.

---

Lastly some good references that will help you :

Deep Dive on Initialize from Backup for Transactional Replication

Replicating Non-Clustered Indexes Improves Subscriber Query Performance

Follow the Data in Transactional Replication - Whitepaper

Troubleshooting Transactional Replication

Scaling Out the Distribution Database

Answer 2

It really depends on your overhead and how well you can manage that. If you're not on a super busy system then you should be fine, but maintain a baseline before setting it up and compare the results after to see what the impact was.

Hilary Cotter, one of the authorities of replication, had told me that don't worry about it for having 5 publishers using a single distributor, after that, pay careful attention.

If your two links are across a high latency or WAN, I'd highly recommend this article. It goes through how the log reader/log writer command buffers might slow you down a lot if you have the distributor on the same side as the subscriber and how.