Re: Upgrade to 2.3.40 -> failed index

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On February 4, 2008 7:22:09 PM -0800 "Paul B. Henson" <henson@acm.org> 
wrote:

> On Mon, 4 Feb 2008, Quanah Gibson-Mount wrote:
>
> > slapadd always creates at least one log file that would not be removed by
> > automatic removal.  If you had no log files when you were done, then
> > something was done wrong.
>
> There's not much to slapadd, I'm not sure what could have been done
> wrong... I did use the -q option (otherwise it takes untractably long),
> but there were no errors or interruptions and the database created worked
> fine for 10 months or so.

Let me expand slightly.  If you *correctly* clean up the environment after 
slapadd finishes, you will have none non-archivable log file:

Here's the add:
[zimbra@freelancer openldap-data]$ /opt/zimbra/openldap/sbin/slapadd -b '' 
-q -f /opt/zimbra/conf/slapd.conf -l /tmp/output.ldif
[zimbra@freelancer openldap-data]$ ls
DB_CONFIG  __db.002   alock   db         entryCSN.bdb   id2entry.bdb  logs 
objectClass.bdb  uid.bdb               zimbraId.bdb
__db.001   accesslog  cn.bdb  dn2id.bdb  entryUUID.bdb  ldap.bak 
mail.bdb  sn.bdb           zimbraDomainName.bdb
[zimbra@freelancer openldap-data]$ ls logs/
[zimbra@freelancer openldap-data]$ /opt/zimbra/sleepycat/bin/db_recover
[zimbra@freelancer openldap-data]$ ls
DB_CONFIG  accesslog  alock  cn.bdb  db  dn2id.bdb  entryCSN.bdb 
entryUUID.bdb  id2entry.bdb  ldap.bak  logs  mail.bdb  objectClass.bdb 
sn.bdb  uid.bdb  zimbraDomainName.bdb  zimbraId.bdb
[zimbra@freelancer openldap-data]$ ls logs/
log.0000000001
[zimbra@freelancer openldap-data]$ /opt/zimbra/sleepycat/bin/db_archive
[zimbra@freelancer openldap-data]$

So you can see here -- Slapadd completes.  Now, it only creates a partial 
BDB environment (That's why there are two __db.* files).  After it 
completes, before you can copy it anywhere, you need to run db_recover to 
clean that environment out, which I noted quite a long time ago.

You can see that once that is done, the log file is generated, and that it 
is contains data necessary for recovery (which is why db_archive returns 
nothing).  Way back at the beginning of this thread, I asked if you 
properly ran db_recover to clean up the environment first, the answer is 
obviously no.

As -q notes:

      -q     enable quick (fewer integrity checks) mode.  Does fewer 
consis-
	      tency  checks  on the input data, and no consistency checks when
	      writing the database.  Improves the load time but if any	errors
	      or  interruptions occur the resulting database will be unusable.

See the bit about no consistency checks when writing the DB.  You need to 
run the db_recover after the add to finish up.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration