CODEWITHSUNDEEP
sqlsql-servertransactionsreplicationsnapshot
Daim Yakub
Daim Yakub

Reputation: 31

Transactional Replication or Snapshot Replication For My Situation

I'm currently working on a project for a company, the company has 8 branches, each with their own server. They task me to combine the db into one to be used at the headquarter. Maybe I'm stupid but the only way that I can come up with is to replicate each database to HQ. So then HQ will have 8 database of each branches. Problem is they want data changes to be real time, so I figured snapshot isn't going to work.

So I opted to transaction, which works but from my testing, I tried deleting some record at HQ database first, then I deleted the same record from the publisher/branches. And I got this error when it tries to replicate the database,

"The row was not found at the Subscriber when applying the replicated DELETE command for Table '[dbo].[repl_tbl]' with Primary Key(s): [id] = 1 (Source: MSSQLServer, Error number: 20598)"

Another problem that I found is that, If I were to add new data with let say primary key '15' to the branch database at my HQ which currently doesn't exist yet, and then I add data with primary key '15' to the branch/publisher database, now this result in error of

"Violation of PRIMARY KEY constraint 'PK_repl_tbl'. Cannot insert duplicate key in object 'dbo.repl_tbl'. The duplicate key value is (13). (Source: MSSQLServer, Error number: 2627)"

I'm expecting the data at HQ to changed according to branch.

Any suggestion is greatly appreciated. Thanks in advance.

Upvotes: 1

Views: 956

Answers (1)

andrews
andrews

Reputation: 2173

If changes must be reflected at each side in real time and are to be made at both publisher and subscriber then you may want to look at Merge Replication, not Transaction or Snapshot one:

https://learn.microsoft.com/en-us/sql/relational-databases/replication/merge/merge-replication?view=sql-server-2017

Merge replication is a bit more complex and if any issues happen to it you can't simply reinitialize subscription at Publisher because you will loose non-synchronized data at subscriber like the issue described in this question . But from your description it may be a way to go.

However, merge, snapshot or transaction replication mostly deals with individual published tables then whole databases. If you need to make available at HQ complete databases from branches then you may want to look at another technology called Always On Availability Groups. With AGs you can easily make remote DBs available for HQ but it requires Windows Failover Cluster setup between branches and HQ first. Among limitations of AGs is that the secondary replica databases are read-only. Changes can only be done at Primary replica.

HTH

Upvotes: 2

Related Questions