[Date Prev][Date Next]
Re: slurpd vs ldapsync
Emmanuel Dreyfus wrote:
On Thu, Mar 22, 2007 at 02:44:19AM -0700, Howard Chu wrote:
Problems with slurpd have been discussed on the lists and recorded in
the ITS many times over the years. I'll just recap briefly:
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?
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
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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/