Slurpd replication has been deprecated in favor of Syncrepl replication and has been completely removed from OpenLDAP 2.4.
Why was it replaced?
The slurpd daemon was the original replication mechanism 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 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
Why is Syncrepl better?
- Syncrepl is self-synchronizing; you can start with a database in any state from totally empty to fully synced and it will automatically do the right thing to achieve and maintain synchronization
- Syncrepl can operate in either direction
- Data updates can be minimal or maximal
How do I implement a pushed based replication system using Syncrepl?
The easiest way is to point an LDAP backend (Backends and slapd-ldap(8)) to your slave directory and setup Syncrepl to point to your Master database.
REFERENCE test045/048 for better explanation of above.
If you imagine Syncrepl pulling down changes from the Master server, and then pushing those changes out to your slave servers via slapd-ldap(8). This is called proxy mode (elaborate/confirm?).
DIAGRAM HERE
BETTER EXAMPLE here from test045/048 for different push/multiproxy examples.
Here's an example:
include ./schema/core.schema
include ./schema/cosine.schema
include ./schema/inetorgperson.schema
include ./schema/openldap.schema
include ./schema/nis.schema
pidfile /home/ghenry/openldap/ldap/tests/testrun/slapd.3.pid
argsfile /home/ghenry/openldap/ldap/tests/testrun/slapd.3.args
modulepath ../servers/slapd/back-bdb/
moduleload back_bdb.la
modulepath ../servers/slapd/back-monitor/
moduleload back_monitor.la
modulepath ../servers/slapd/overlays/
moduleload syncprov.la
modulepath ../servers/slapd/back-ldap/
moduleload back_ldap.la
# We don't need any access to this DSA
restrict all
#######################################################################
# consumer proxy database definitions
#######################################################################
database ldap
suffix "dc=example,dc=com"
rootdn "cn=Whoever"
uri ldap://localhost:9012/
lastmod on
# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply
# without the need to write the UpdateDN before starting replication
acl-bind bindmethod=simple
binddn="cn=Monitor"
credentials=monitor
# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply
# without the need to write the UpdateDN before starting replication
syncrepl rid=1
provider=ldap://localhost:9011/
binddn="cn=Manager,dc=example,dc=com"
bindmethod=simple
credentials=secret
searchbase="dc=example,dc=com"
filter="(objectClass=*)"
attrs="*,structuralObjectClass,entryUUID,entryCSN,creatorsName,createTimestamp,modifiersName,modifyTimestamp"
schemachecking=off
scope=sub
type=refreshAndPersist
retry="5 5 300 5"
overlay syncprov
database monitor
DETAILED EXPLANATION OF ABOVE LIKE IN OTHER SECTIONS (line numbers?)
ANOTHER DIAGRAM HERE
As you can see, you can let your imagination go wild using Syncrepl and slapd-ldap(8) tailoring your replication to fit your specific network topology.
