[Date Prev][Date Next]
Slurpd cannot handle multiple replica statements for a single slave server (ITS#2137)
Full_Name: Bruno Spieler
OS: Solaris 8
Submission from: (NULL) (188.8.131.52)
My configuration is the following (multimaster option NOT enabled) :
Two slapd servers : ldap1.mydomain.com and ldap2.mydomain.com, each of which
handling four back-ends (BDB):
- BE #1 for suffix "o=myRoot"
- BE #2 for suffix "ou=pub1,o=myRoot" (subordinate)
- BE #3 for suffix "ou=pub2,o=myRoot" (subordinate)
- BE #4 for suffix "ou=private,o=myRoot" (subordinate)
I'd like to define replication agreements between ldap1 and ldap2 so that :
- ldap1 is master on "ou=pub1,o=myRoot" and "ou=pub2,o=myRoot" and replicates
them towards ldap2 (slave)
- ldap2 is master on "ou=private,o=myRoot" and replicates it (some attributes
are filtered, but its does not matter here) towards ldap1 (slave)
No replication occurs at root level. No problem to set up replication from ldap2
to ldap1. The problem is to set up the replication from ldap1 to ldap2.
To do this, I added two "replica" statements in ldap1 configuration file, with
the same "host" parameter set to ldap2.mydomain.com and no "suffix" parameter.
In this case, slurpd on ldap1 get confused : when adding an entry in
"ou=pub1,o=myRoot" for exemple, each thread of slurpd (one per replica
statement) tries to perform the same add operation on the ldap2. Ldap2
logically complains about the second update.
I guess the problem is linked to the way used by slurpd to identify the replica
agreements : "hostname:port" in the *.rej files but also in the slurpd.status
and in the slurpd.replog ("replica" statement).
Indeed, a workaround that worked fine for me (no DNS nor DHCP stuff) is to add
an alias for ldap2.mydomain.com (let's say ldap2-alias.mydomain.com) in my
/etc/hosts file on ldap1, and to use the "ldap2.mydomain.com" as "host"
parameter for the first replica statement and "ldap2-alias.mydomain.com" for the
A solution could be to add a new parameter to the replica statement: something
like agreementId="pub1replica" for example. The administrator would be in charge
of the unicity of this parameter among all the replica statements of a single
slapd configuration file, so that slurpd could use it to uniquely identify the
various replication agreements.
A simpler solution could also be to make slurpd identify the various agreements
with something like "host:port:back-end-id" instead of "host:port", where
back-end-id would be the number of the back-end concerned by the replica
statement. Less handy when adding future back-ends definitions...
I also tried another solution : I replaced both replica statements by a single
"replica" statements in ldap1 configuration file, at the root back-end level
this time, with two "suffix" parameters : suffix="ou=pub1,o=myRoot" and
suffix="ou=pub2,o=myRoot", but no replication occurs at all in this case (seems
ok since the root back-end is not responsible for these suffixes).