[Date Prev][Date Next]
Re: (ITS#3859) Strange replication and search problems
Ludovic Drolez wrote:
> Pierangelo Masarati wrote:
> > Ludovic Drolez wrote:
> >> Version: 2.2.23 OS: Debian 3.1 sarge
> >> Hi !
> >> We are currently replicating an openldap 2.0.23 directory to a
> >> 2.2.23 one, and modified entries have a corrupt index on
> >> 'objectClass' (we are using the ldbm backend).
> >> Steps to reproduce: 1- make an initial slapcat;slapadd to
> >> synchronize the two servers. 2- 'ldapsearch -x -h slave
> >> objectClass=posixAccount|grep toto' returns the entry (there are
> >> less than 500 entries) 3- modify something on the master 4- the
> >> same ldapsearch now returns nothing (but a 'ldapsearch -x'
> >> without a filter on the objectClass is ok). 5- if I remove 'index
> >> objectClass eq' from the slave server, then the 'ldapsearch' is
> >> ok.
> >> So it seems that the replication corrupts the index. I can also
> >> reproduce the bug with slapd 2.2.26.
> >> Is this bug related to 'Software Bugs/3406' ? Or is it only a
> >> replication problem ?
> > I note that replication from 2.0 to 2.2 should be impossible
> > because the 2.2 slave expects stuff like structuralObjectClass,
> > entryUUID, entryCSN. I don't see how ITS/3406 may be related to
> > this.
Just echoing Pierangelo here. A 2.2 slave will reject a slurpd update
that doesn't provide the structuralObjectClass, and a 2.0 server doesn't
supply this attribute. And I don't see any connection to ITS#3406 at
all, perhaps you meant some other ITS#?
> I thought that only the contrary was impossible (2.2 to 2.0), and I
> don't get syntax errors during the replication. How could a
> replication corrupt the index?
In 2.0 index corruptions occurred quite frequently. In 2.2 back-ldbm
they are less common but may still occur. Regardless, replication from
2.0 to 2.2 is not possible, as already stated. If you are actually
getting replication to occur from a 2.0 master to a 2.2 slave then
either your master or slave software have been modified and are
different from OpenLDAP software. Since we have no idea what changes
have been made to your code, you're going to have to seek help from
whoever modified it.
-- 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/