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
replica: <host>[:<port>]
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
# ...
database bdb
suffix "dc=domain1"
# ...
replica host=slave:389
binddn="cn=Replica,dc=domain1" ...
replogfile /var/ldap/domain1/slapd.replog
database bdb
suffix "dc=domain2"
# note the "host" below differs from the previous one only in the case...
replica host=SLAVE:389
binddn="cn=Replica,dc=domain2" ...
replogfile /var/ldap/domain2/slapd.replog
and
# slave slapd.conf
# ...
database bdb
suffix "dc=domain1"
# ...
updatedn "cn=Replica,dc=domain1"
updateref ldap://master
database bdb
suffix "dc=domain2"
# ...
updatedn "cn=Replica,dc=domain2"
updateref ldap://master
with the daemons started as
[ldap@master]$ slapd
[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
and
[ldap@slave]$ slapd
should do the trick.
Updates in the first replog, "/var/ldap/domain1/slapd.replog", will look like
replica: slave:389
time: 797612941
dn: cn=Name,dc=domain1
changetype: modify
delete: description
-
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:
replica: SLAVE:389
time: 797612942
dn: cn=Name,dc=domain2
changetype: modify
delete: description
-
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.
|