[389-users] Re: Index corruption message in multimaster replication

On 07/17/2017 02:53 AM, William Brown wrote:

On Sun, 2017-07-16 at 19:49 +0000, tdarby@email.arizona.edu wrote:  

Which version of 389-ds-base do you have configured?   

    I'm running on RHEL 6.9  In the errors log, it shows 389-Directory/1.2.11.15 B2015.345.187  The RPM for it is 389-ds-base-1.2.11.15-69.el6_7.x86_64 is the RPM  

  I'll need to check with the team, but I do not believe we are supporting  this version any more. We have some newer 1.2.x series release, but we  won't backport fixes to anything in this series (even if we find the  root cause).    

Sorry, there is no way to see which index it is easily. It looks like a  

substring index, but you likely need to correlate this to an access log  

that made a query of "*zon".  

    I searched all the access logs there and couldn't find a string matching *zon. Subsequently, another identical error message showed up for the string "*urs". I was not able to find that in the access logs either.    So, I started doing dbscans on the indexes and eventually found two that are most likely the culprits, cn.db4 and ismemberof.db4. In the dbscans for these I found the following:    cn.db4:  *urs                                    403595  *zon                                    409451    ismemberof.db4:  *urs                                    403926  *zon                                    666628    Are you saying then that I may not actually have a corrupt index?  

  Correct. I think the issue is we don't have enough space to read in your  index during a search process. I suspect it's the later index, for  ismemberof. I'll see if I can reproduce this on my system.     For now a solution *could* be to remove substr on ismember of and cn,  and allow the other indexes to be searched. It would be good to see the  queries that cause the issue because that could help me advise better on  if this is an adquete temporary work around. 

the buffer cannot really be to small, in c_get(... DB_MULTIPLE) we provide the buffer and its size and the buffer will be filled by the bdb functions. Since in a substring index our key always has a size of 4 and the data is an ID with size 4 always at least one key/data pair will fit.

But there are two issues, the BUFFER_SMALL was on one server and the *zon error on the other. And it explicitely said that the data size was 5 instead of the expected 4, so this indicates that there is really someting broken in that index.

I would suggest to combine your and Mark's proposal: remove the substring index and reindex the database

_______________________________________________  389-users mailing list -- 389-users@lists.fedoraproject.org  To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org  

--   Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,   Commercial register: Amtsgericht Muenchen, HRB 153243,  Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander