In 2.2 (but likely in earlier versions as well) a slapd holding more than one database can use a single replog for all databases or a replog for each database or a mix of the two.
The choice is essentially based on considerations about the type of data protection you want to give to the replog; for instance, two databases containing data related to two different customers should likely be replicated to two separate replogs, contained in different directories with appropriate ownership and permissions.
Each replog needs a specific instance of slurpd, run with the appropriate -r switch to indicate what replog to use, and the appropriate -t switch to make them use different working directories; see slurpd(8) for details.
Unfortunately, when slurpd is started, it creates as many threads as are the replica lines in slapd.conf(5), even for those not related to the replog it is currently using.
Updates in replogs are prefixed by lines of the form
one for each replica. Each thread of slurpd determines what updates to propagate based on this key. It should be clear that if the same slave DSA is hosting separate replicas of separate databases there is an ambiguity, because different threads of slurpd, serving different slave databases, will recognize the same replica: line as theirs.
At present, the only known means to avoid this ambiguity is to use host names that differ in letter case, since slurpd uses a case exact match to check the host name, while the DNS is case insensitive; so:
# master slapd.conf
# note the "host" below differs from the previous one only in the case...
# slave slapd.conf
with the daemons started as
[ldap@master]$ slurpd -t /var/ldap/domain1 -r /var/ldap/domain1/slapd.replog
[ldap@master]$ slurpd -t /var/ldap/domain2 -r /var/ldap/domain2/slapd.replog
should do the trick.
Updates in the first replog, "/var/ldap/domain1/slapd.replog", will look like
See slapd.replog(5) for details on the format. The instance of slurpd that was instructed to process the first replog will read the replica: line and, since it's lowercase, will instruct the first thread to process it. Of course in this replog there will never be any line containing a replica: line of the form
replica: SLAVE:389, so the second thread of slurpd will just remain idle.
The same will occur to the slurpd that's processing the other replog, "/var/ldap/domain2/slapd.replog", but all entries in this replog will appear with the uppercase form of the hostname:
and they will be processed by the second thread of the instance of slurpd that is processing the second replog; the first thread will just remain idle, since no
replica: slave:389 line will appear in the second replog.