On 07/10/2010 15:45, Quanah Gibson-Mount wrote:
--On Thursday, October 07, 2010 12:59 PM +0200 Christian Manal moenoel@informatik.uni-bremen.de wrote:
Hi,
I think you misunderstood the docs there. If you speak about "push replication" you mean "RefreshAndPersist", right? That doesn't mean that the master connects to the slaves and pushes the changes to them.
With "RefreshAndPersist" the slaves connect to the master and keep that connection open indefinitely (and reconnect if it goes down), waiting for the master to "push" changes through that open connection.
Actually, you apparently misunderstood the docs. ;) RefreshAndPersist is "pull" replication. I suggest reading the admin guide, which discusses how to set up push-based replication.
I think there is some confusion going on here between 2 things: 1) Which server initiates the (TCP) connection to the other 2) Which server pulls/pushes modifications to/from the other
Put simply, with slurpd the master server connected to all slaves, and pushed modifications.
With syncrepl, it is usual for slaves (called consumers) to connect to the master (called provider), and pull changes (ie, "tell me what has changed since last time").
However, there are some possible variations on this basic model, with syncrepl:
1) If for some firewalling/networking related reason you can't/don't want to have slaves initiating TCP connections to the master, you can setup a proxy system on the master so that the master initiates the connection from a TCP point of view.
2) Using refreshAndPersist, a slave (consumer) server will connect to the master (provider) and request changes (pull), but then remain connected and get notification of any future changes as they happen. This may look like push, but it's more of a subscriber based relation.
Hope this clears some things up!
Jonathan