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_...
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.