Merge Replication

Question

Merge Replication

dastagiri16

Hall of Fame

Points: 3544
More actions
May 10, 2016 at 1:02 pm

#400138

Can we configure Merge Replication ..
Like sever A(publisher) - server b(subscriber) and sever b(publisher) to server C(subscriber) ?

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

Alan Burstein SSC Guru Points: 61141 More actions · Answer 1

I can't see why not.

"I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

-- Itzik Ben-Gan 2001

Brandie Tarvin SSC Guru Points: 173061 More actions · Answer 2

dastagiri16 (5/10/2016)
Can we configure Merge Replication ..
Like sever A(publisher) - server b(subscriber) and sever b(publisher) to server C(subscriber) ?

The only way to know is to try it. But really, this setup isn't Merge Replication. It's either transactional or snapshot.

Merge Replication takes data from all servers and duplicates it to all servers. So C would be a publisher to B and A. A would be a publisher to B and C. B would be a publisher to C and A.

If you want to do it as above, then schedule transactional or snapshot in the order you've listed. But don't use Merge.

EDIT: I'm working off what I learned from SQL 2000, which is the last time I dealt with replication. Things may have changed, but I don't think they've changed that much.

Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

Alan Burstein SSC Guru Points: 61141 More actions · Answer 3

Brandie Tarvin (5/11/2016)
dastagiri16 (5/10/2016)
Can we configure Merge Replication ..
Like sever A(publisher) - server b(subscriber) and sever b(publisher) to server C(subscriber) ?
The only way to know is to try it. But really, this setup isn't Merge Replication. It's either transactional or snapshot.
Merge Replication takes data from all servers and duplicates it to all servers. So C would be a publisher to B and A. A would be a publisher to B and C. B would be a publisher to C and A.
If you want to do it as above, then schedule transactional or snapshot in the order you've listed. But don't use Merge.
EDIT: I'm working off what I learned from SQL 2000, which is the last time I dealt with replication. Things may have changed, but I don't think they've changed that much.

I last did any real replication in SQL Server 2008 but you can do merge in this scenario. You could also have a mix of snapshot and/or transactional and/or merge in this scenario depending on your needs.

"I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

-- Itzik Ben-Gan 2001

Brandie Tarvin SSC Guru Points: 173061 More actions · Answer 4

Alan.B (5/11/2016)
I last did any real replication in SQL Server 2008 but you can do merge in this scenario. You could also have a mix of snapshot and/or transactional and/or merge in this scenario depending on your needs.

Thanks for the correction, Alan. But from a technical definition standpoint, is it really merge if the data is flowing downstream from one server to another? Doesn't merge require reciprocal data flow?

Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

Alan Burstein SSC Guru Points: 61141 More actions · Answer 5

Brandie Tarvin (5/11/2016)
Alan.B (5/11/2016)
I last did any real replication in SQL Server 2008 but you can do merge in this scenario. You could also have a mix of snapshot and/or transactional and/or merge in this scenario depending on your needs.
Thanks for the correction, Alan. But from a technical definition standpoint, is it really merge if the data is flowing downstream from one server to another? Doesn't merge require reciprocal data flow?

I wasn't trying to correct you, it way have been different with 2000 - I never did replication with SQL Server 2000 (I heard bad things about it then).

I could be wrong (again, it's been a few years) but it's transactional replication when you set up transactional replication and use the log reader agent, it's merge when you set up merge replication and use the merge agent. The merge agent enables you to do true bi-directional merge replication but it can be one way as well using the merge agent. So, by "merge replication" I'm speaking to the server configuration.

There are some cases where I have used the merge agent in the past that had nothing to do with merge replication. We were doing replication between Battle Creek MI, and Soth Africa and Somewhere in Brazil. It was one way with the publisher in Mi, subscribers in the other two places. The South Africa connection was real bad and we had many problems. A Microsoft Consultant suggested using the Merge agent instead of the log reader because the merge agent handled bad connections better. This solved the problem and the client is doing transactional using the merge agent still today.

"I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

-- Itzik Ben-Gan 2001

Brandie Tarvin SSC Guru Points: 173061 More actions · Answer 6

Alan.B (5/11/2016)
There are some cases where I have used the merge agent in the past that had nothing to do with merge replication. We were doing replication between Battle Creek MI, and Soth Africa and Somewhere in Brazil. It was one way with the publisher in Mi, subscribers in the other two places. The South Africa connection was real bad and we had many problems. A Microsoft Consultant suggested using the Merge agent instead of the log reader because the merge agent handled bad connections better. This solved the problem and the client is doing transactional using the merge agent still today.

Now that's an interesting tidbit. I'll have to remember it for future use.

Thank you for clarifying the comment.

Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.