Ever since I first layed hands on OpenLDAP, I’ve been
accustomed to synchronizing the master server with a number of slaves
utilizing slurpd. This has always worked very well for us and, being a
push replication, it has the advantage that it can easily be monitored for
errors in the replication. The reject files created by slurpd if updates
couldn’t be performed on the slaves can easily be monitored and the
replication log file itself can be monitored for “growth”, which indicates
that one or more slave servers have gone South. For the dozen (!) mini mail
servers I’m installing very far away from Europe, I’ve opted for
OpenLDAP’s LDAP sync replication, in which the slaves “pull” updates from
the master. Let me begin by saying that I’m bloody impressed by its
performance. I’m implementing delta-syncrepl in “refreshAndPersist” mode.
The slave (called a consumer) connects to the master (the provider) and pulls
the LDAP modifications the latter has recorded it its access log. The
“Persist” bit means that the consumer keeps the connection open to the
provider, receiving updates almost instantaneously when they occur on the
provider. So far so good. What is a bit difficult in this scenario is to
monitor that the updates are being “consumed” (i.e. that the slave is pulling
the updates). In order to monitor this, I’m periodically updating a counter on
the master and using a custom built Nagios plugin to check the value of
the counter on the slaves. Time will tell if this is the best implementation,
but I think it should be ok. I’ve probably said this a hundred times before,
but I gladly repeat myself: the OpenLDAP team has created a fabulous bit of
software. Thank you!