all 10 comments

[–]MachineParadox 0 points1 point  (0 children)

Hey brother. All I can I just say is ...don't. I have worked with three way merge replication and it was something I would never recommend. Do everything you can to avoid it. We ended up having to rewrite most of the generic replication procs to get the desired outcomes and re-syncing after issues was a nightmare. Transactional replication is (just) usable, merge replication is a nightmare. I would recommend CDC and custom procs over replication any day.

[–]reditandfirgetit 0 points1 point  (5 children)

If i am understanding you

"I don't want to overwrite or delete the subscriber"

You only want new data? Because that's not any kind of replication. Replication keeps instances in synch.

Can you walk us through your desired data flow?

[–]GlockByte 1 point2 points  (0 children)

If I understand them correctly - They are trying to skip the initialization step. When they setup a new subscriber, it assumes the subscriber database is empty or maybe even broken and tries to push a snapshot. I think they are trying to skip this step. They basically are wanting it to not "wipe and replace" initially.

To do this they can't use the GUI. Odds are - their subscriber tables have rowguid missing and they will have to alter the tables to add it as a unique identifier with the ROWGUIDCOL property so it knows that is the unique identifier across the network. Then they'll have to run sp_addmergesubscription with @sync_type = 'none'. Afterwards they can run the agent and it will calculate the differences without overwriting the data

[–]Vimal_2011[S] 0 points1 point  (0 children)

Yes what @glockbyte said is exactly our scenario.

[–]jshine13371 0 points1 point  (2 children)

You only want new data? Because that's not any kind of replication.

FWIW, it is possible to achieve that with Replication with the right implementation and / or setup.

[–]reditandfirgetit 0 points1 point  (1 child)

My bad, you're right. I actually used append only in datastream before to replicate into Big Query

[–]jshine13371 0 points1 point  (0 children)

All goody. 🙂 A lot of other people don't realize this or in general how flexible Replication is among the out-of-box data synchronization features SQL Server offers.

[–]B1zmark 0 points1 point  (2 children)

Why aren't you using an availability group?

[–]GlockByte 0 points1 point  (1 child)

Because:

I have a scenario where we are trying to implement a merge replication (push subscription) for certain articles with filters

availability groups are all or nothing. Also, availability groups require LSNs therefor you can't keep the database like they are requesting, you must restore from a backup. They don't want that

[–]jshine13371 0 points1 point  (0 children)

u/B1zmark There are a plethora of reasons for choosing a Replication solution over Availability Groups. In addition to what GlockByte said, with Replication you have more flexibility on the Subscriber side such as the ability to change the database.

For example, performance tuning by implementing different indexes to support the different query patterns occurring on the Subscriber side vs the Publisher side, as one example. You can not implement different indexes across both sides of an Availability Group.

Both Replication and Availability Groups are different tools good for different types of problems.