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!