quick save.

This commit is contained in:
Gavin Henry 2007-06-27 23:03:45 +00:00
parent 73ad5a7217
commit b4eddbb2a2

View File

@ -1,4 +1,4 @@
# $OpenLDAP$
# $OpenLDAP$
# Copyright 1999-2007 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
@ -29,24 +29,26 @@ H5: Replacing Slurpd
Slurpd replication has been deprecated in favor of Syncrepl replication and
has been completely removed from 2.4.
The slurpd daemon; inherited from UMich's LDAP, operates in
push mode: the master pushes changes to the slaves.
{{Why was it replaced?}}
It has been replaced for many reasons, in brief:
The slurpd daemon was the original replication mechanisim inherited from
UMich's LDAP and operates in push mode: the master pushes changes to the
slaves. It has been replaced for many reasons, in brief:
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.
- 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 directory
- It 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
{{What was it replaced with?}}
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.
* Replication via syncrepl, the LDAP content synchronization operation (LDAP sync, RFC 4533). Introduced in OpenLDAP 2.2, it operates in pull mode: the consumer pulls the updates out of the producer. When used in refreshOnly mode, the producer barely knows it's acting as a master, while the refreshAndPersist mode requires the producer to support persistent searches. Either mode requires the provider and the consumer to support the controls related to the Sync Operation.