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

Re: Upgrade to 2.3.40 -> failed index

--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/
[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 Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration