Re: Inconsistent syncrepl behaviour with glue records (ITS#3133)

[jongchoi@OpenLDAP.org]

I've just committed a small patch for this which blocks chasing the links
through the glued databases when a sync control is attached to searches. As
a result, the scope of a syncrepl specification will be limited within the
database it is defined. The database structures of the provider and the
consumer needs to be matched and each database needs to be replicated by
separate replication specification. It should be also possible to replicate
multiple provider databases which are glued together into a single consumer
database by having multiple sync replication specifications to the
corresponding provider databases inside a single consumer database
definition.
More general treatment of replication for the glued database deserves more
thought. For example, in order to support splitting a single provider
database into multiple consumer databases, it might be required to have sth
like X.500 subtree specification to have a fine control over the replication
area.
The patch worked for a DIT spanning over two glued databases. Let me know
whether it works for your configuration.
- Jong-Hyuk

----- Original Message ----- 
From: <lukeh@padl.com>
To: <openldap-its@OpenLDAP.org>
Sent: Wednesday, May 05, 2004 11:18 PM
Subject: Inconsistent syncrepl behaviour with glue records (ITS#3133)


> Full_Name: Luke Howard
> Version: 2.2.10
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (165.228.130.12)
>
>
> I am using OpenLDAP 2.2.10 with the patch in ITS#3131.
>
> The master DSA has three databases, each immediately subordinate to the
next.
> The relevant sections of the configuration file on the master follow:
>
> ---CUT HERE---
> defaultsearchbase "DC=foo,DC=bar"
>
> database hdb
> suffix "CN=A,CN=B,DC=foo,DC=bar"
> <snip>
>
> database hdb
> suffix "CN=B,DC=foo,DC=bar"
> <snip>
>
> database hdb
> suffix "DC=foo,DC=bar"
> <snip>
>
> database dnssrv
> suffix ""
> ---CUT HERE---
>
> The replica configuration is similar, in that there are three databases
(each
> for shadowing the corresponding one on the master) and a default search
base and
> the DNS SRV backend are both enabled. The relevant sections from the
replica
> configuration file follow:
>
> ---CUT HERE---
> database hdb
> suffix "CN=A,CN=B,DC=foo,DC=bar"
> lastmod on
> <snip>
> syncrepl rid=1
>   provider=ldap://master
>   updatedn="CN=manager,DC=foo,DC=bar"
>   binddn="CN=replicaDN,DC=foo,DC=bar"
>   bindmethod=sasl
>   saslmech=GSSAPI
>   secprops=minssf=56
>   searchbase="CN=A,CN=B,DC=foo,DC=bar"
>   filter="(objectClass=*)"
>   attrs="*"
>   schemachecking=off
>   scope=sub
>   type=refreshOnly
>   interval=00:00:00:10
>
> updateref ldap://master
> ---CUT HERE---
>
> The above stanza is repeated twice with the suffix and searchbase changed,
for
> both "CN=B,DC=foo,DC=bar" and "DC=foo,DC=bar".
>
> Now, to explain the problem:
>
> After provisioning the replica, sometimes the entry at "DC=foo,DC=bar" is
synced
> correctly from the master, and at other times a glue record is stored. I
suspect
> that this is a race condition dependent on which database finishes syncing
> first. Because the entry at "DC=foo,DC=bar" on the master contains
useful
> information on which our application depends, the glue record breaks our
> application when it uses a replica. As it happens I can duplicate this
problem
> on one replica DSA, running on Fedora Core 1 under VMware, but not
another,
> running on SuSE 9.0 on real hardware. However, I have seen the problem
manifest
> on the latter system in the past.
>
> The glue record appears as follows (DN has been changed for privacy):
>
> ---CUT HERE---
> # slapcat -n 3
> dn: dc=foo,dc=bar
> structuralObjectClass: glue
> objectClass: top
> objectClass: glue
> ---CUT HERE---
>
> whereas it should really be an instance of object class "domain".
>
>
>
>
>
>