RE: cleaning up logs from bdb db and upgrading ldap

["Douglas B. Jones" <douglas@gpc.edu>]

Sorry it has taken me to so long to reply. I want to thank
everyone for your help on both cases. I do have a further
question on the log rotation part. 

I added:

set_flags DB_LOG_AUTOREMOVE

to the DB_CONFIG file. When I restarted the daemon, I did not
see any difference in the number of log.* files. Since I rebuilt
the db yesterday, the only log.* file to be modified when I restarted it
today was the last one numerically speaking. I am guessing, since this
particular ldap port has not had any activity except some reads, that

1) only the last log would be modified since restarting
2) the number of logs I have would always start with this much whenever
   I rebuild (slapcat/slapadd)
3) to see more logs, then more activity would have to happen and then
   I would start to see some logs be removed.

Is this right? Also, reading in the documentation:

http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html#DB_LOG_AUTOREMOVE

It notes:

"If set, Berkeley DB will automatically remove log files that are no longer needed. 
Automatic log file removal is likely to make catastrophic recovery impossible."

So, I worry. Is there a way to reduce the number of log files and be able
to be safe against catastrophic problems? I am guessing the only way to
do this is to rebuild the db from scratch via slapcat/slapadd? Thanks for
any help!

-----Original Message-----
From: openldap-software-bounces+douglas=gpc.edu@openldap.org [mailto:openldap-software-bounces+douglas=gpc.edu@openldap.org] On
Behalf Of Dave Horsfall
Sent: Tuesday, January 30, 2007 11:13 PM
To: OpenLDAP Software List
Subject: Re: cleaning up logs from bdb db and upgrading ldap

On Tue, 30 Jan 2007, Howard Chu wrote:

> > Only when upgrading between major versions e.g. 2.2.X -> 2.3.X.
> 
> Technically that is the minor version number. I.e., an OpenLDAP release 
> number is major.minor.patch. In the 2.x releases we've had database 
> format changes for each minor release thus far, but probably won't have 
> any format changes in 2.4.
> 
> And actually, the format only changed between 2.2 and 2.3 for 
> little-endian machines like Intel x86. On big-endian machines like 
> Sparc, there was no change. Now we consistently use big-endian byte 
> order everywhere.

Corrections noted; thanks.

-- 
Dave Horsfall  DTM  VK2KFU  daveh@ci.com.au  Ph: +61 2 9552-5509 (d) -5500 (sw)
Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU