[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syncrepl and glue



The answer is in the description for "subordinate" in slapd.conf(5). You have to exchange the order of the syncprov and glue overlays to prevent the provider from descending into the glued databases.

Spicer, Kevin wrote:
I'm attempting to migrate from slurpd replication to syncrepl, however
I'm having some problems which I think arise from the way my tree is
glued together.  I've taken a look at test33, however my database setup
is somewhat more complex than that  and I think this is where my
problems are coming from...

This is what test33 does...
_________________________________ | dc=example,dc=com /
db1 | / \____________
| ou=People / | ou=Groups |
|____________________________/ | | db3
__________________|__________________ | (entries) |
db2 | ou=Information Technology Division | |___________|
| |
| (entries) |
|____________________________________|


Where the three dbs are glued together, db1 is not replicated, db2 is a
syncrepl provider on one slapd instance and a consumer on the other, db3
is the other way around.

Compare this to my existing setup using slurpd (simplified version)

________________________________________________________________________
_
| dc=example,dc=com
|
|
|
db1| ou=People ou=Groups ou=sites ou=policy ou=printers
(etc..) | | (entries) (entries) ___ (entries) (entries)
|
|_______________________ ou=site1 | |
\___________________________________| |(entries)| |\
|_________| | \
| \
__________| \__________ |ou=site2 | |ou=site3 |
db2 |(entries)| |(entries)| db3
|_________| |_________|


In fact there are more ou's in db1 and two more dbs for sites 4 and 5.
Each server is master for one db and replica for the others and all are
glued together.

I'm currently running 2.3.16 on Solaris 9 with ppolicy overlay.  The
above setup has been replicating fine for some time using slurpd.
Attempting to use syncrepl it seems that syncrepl on the top level
database is not restricted to entries within that db.  I'm not sure
whether the issue is at the provider or consumer (or both) as my inital
tests seem to have produced contradictory results (one test appears to
have overwritten the entries in db2 (on the provider) with entires from
its replica on the db1 master server, and a second test deleted all the
entires in db2 (on the provider).

Does anyone know if its even possible to do what I'm trying to do?  And
if so what I might be missing?



--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/