(Answer) (Category) OpenLDAP Faq-O-Matic : (Category) OpenLDAP Software FAQ : (Category) Configuration : (Category) SLAPD Configuration : (Category) Replication : (Answer) How many replogs should I use?

Here's another hint: Use only one replog per backend. It's not obvious from the man page or the OpenLDAP Administrator's Guide that this is required (although the Admin Guide in section 10.4.1 says 1. Add a replica directive for each replica... 2. Add a replogfile directive). This message in the openldap-software list gives a clear explanation: http://www.openldap.org/lists/openldap-software/199907/msg00204.html.
wcooley@nakedape.cc

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.
The replica-pidfile and replica-logfile in slapd.conf(5) are unique, so they are pointless when used in conjunction with multiple replogs, since all instance of slurpd will use the same file, and thus only the last one will be recorded.
[Append to This Answer]
Previous: (Answer) How do I add slaves?
Next: (Answer) Why don't my changes on a slave directory get referred to the specified master?
This document is: http://www.openldap.org/faq/index.cgi?file=1171
[Search] [Appearance]
This is a Faq-O-Matic 2.721.test.
© Copyright 1998-2013, OpenLDAP Foundation, info@OpenLDAP.org