Re: slurpd vs ldapsync

[flo@redflo.de]

Hi,

Just yesterday i set up slurpd for replication. The openldap
documentation points one to slurpd at many places. Example:
http://www.openldap.org/doc/admin23/config.html#Replicated%20Directory%20Service
No word of an alternative. Could someone give some hints in that chapter
and problably in the chapter "14. Replication with slurpd"?
The FAQ-O-Matic says that "multimaster replication is harmful". Is this
still true as you say that syncrepl works with that?

Thanks for the nice piece of software.

Flo

Howard Chu schrieb:
> Emmanuel Dreyfus wrote:
>> On Thu, Mar 22, 2007 at 02:44:19AM -0700, Howard Chu wrote:
>>> Just because the protocol was defined a particular way (consumer
>>> initiated single master replication) doesn't mean it can't be used in
>>> other ways. OpenLDAP is far more flexible than that. We've enhanced
>>> the basic syncrepl functionality a number of different ways
>>> (delta-syncrepl, proxied syncrepl, mirrormode, and multimaster) all
>>> without altering any of the syncrepl protocol definition. All it
>>> takes is a little creativity to assemble the pieces in the proper order.
>>
>> And what are the reasons for not using slurpd? It has less
>> functionnalities,
>> but can it be considered reliable? Should I change my working setup
>> for syncrepl, or can I live with slurpd?
>>
> Problems with slurpd have been discussed on the lists and recorded in
> the ITS many times over the years. I'll just recap briefly:
> 
> No, it is not reliable. It is extremely sensitive to the ordering of
> records in the replog; it can easily go out of sync at which point
> manual intervention is required to resync the slave database with the
> master.
> 
> Syncrepl is self-synchronizing; you can start with a database in any
> state from totally empty to fully sync'd and it will automatically do
> the right thing to achieve and maintain synchronization.
> 
> Slurpd isn't very tolerant of unavailable servers. If a slave goes down
> for a long time, the replog may grow to a size that's too large for
> slurpd to process. Some of these problems are fixable, but there's
> really no point. Syncrepl covers all the bases slurpd did, plus more.
> 
> The slurpd code is going to be deleted from the source tree. Maybe not
> in 2.4 (though I think that's still possible) but certainly by 2.5.