Hi All,
i've read through the replication section of the admin guide, but i'm still not clear on the ff:
1. For push-type setups, do i really need to set up a sync proxy? the docs seem to imply this is necessary only if there are firewall restrictions, yet i haven't seen any examples of a push setup w/o a proxy.
2. Is it possible to set up a push delta-syncrepl scheme?
3. In a syncrepl/delta-syncrepl push setup, how does the master know where the replicas are?
Things were a bit simpler with slurpd...ah, progress B)
tia
Am 07.10.2010 11:15, schrieb plug bert:
Hi All,
i've read through the replication section of the admin guide, but i'm still not clear on the ff:
For push-type setups, do i really need to set up a sync proxy? the docs seem to imply this is necessary only if there are firewall restrictions, yet i haven't seen any examples of a push setup w/o a proxy.
Is it possible to set up a push delta-syncrepl scheme?
In a syncrepl/delta-syncrepl push setup, how does the master know where the replicas are?
Things were a bit simpler with slurpd...ah, progress B)
tia
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.
Regards, Christian Manal
--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.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Am 07.10.2010 15:45, schrieb Quanah Gibson-Mount:
--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.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Ah... my bad. Apparently I wasn't up to date on the admin guide.
If you excuse me, I will now put on my dunce hat and stand in the corner ;(
Regards, Christian Manal
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
openldap-technical@openldap.org
-
Christian Manal -
Jonathan Clarke -
plug bert -
Quanah Gibson-Mount