I noticed the that I am getting a number of bdb logs (log.0000000000 .. 210) so far for one db. What is the proper procedure for consolidating these with openldap while keeping the server process running. We have version 2.3.27, but plan on upgrading to 2.3.33.
The second question: is the best way to migrate from one ldap version to another to slapcat from the old one and the slapadd to the new one? I realize if I do this way, I would in essence have an answer for the first question, but the first one I was wondering from a live point of view.
Thank you for any help, I have not had much time finding an answer in the archives o slapd.conf or slapd.bdb man pages. Thanks!
On Tue, 30 Jan 2007, Douglas B. Jones wrote:
I noticed the that I am getting a number of bdb logs (log.0000000000 .. 210) so far for one db. What is the proper procedure for consolidating these with openldap while keeping the server process running. We have version 2.3.27, but plan on upgrading to 2.3.33.
"db_archive" will tell you which ones can be removed; alternatively you can use "set_flags DB_LOG_AUTOREMOVE" in DB_CONFIG.
The second question: is the best way to migrate from one ldap version to another to slapcat from the old one and the slapadd to the new one? I realize if I do this way, I would in essence have an answer for the first question, but the first one I was wondering from a live point of view.
Only when upgrading between major versions e.g. 2.2.X -> 2.3.X.
Dave Horsfall 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.
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.
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.
On Tue, 30 Jan 2007, Douglas B. Jones wrote:
I noticed the that I am getting a number of bdb logs (log.0000000000 .. 210) so far for one db. What is the proper procedure for consolidating these with openldap while keeping the server process running. We have version 2.3.27, but plan on upgrading to 2.3.33.
I'd recommend DB_LOG_AUTOREMOVE. Barring that, you can run db_archive manually. Check Sleepycat docs for details on either.
The second question: is the best way to migrate from one ldap version to another to slapcat from the old one and the slapadd to the new one? I realize if I do this way, I would in essence have an answer for the first question, but the first one I was wondering from a live point of view.
This is the suggested method for a server migration. Note that a clean shutdown of 2.3.27 -> 2.3.33 is not considered an upgrade in this sense: just stop slapd 2.3.27, drop in the 2.3.33 slapd binary and go.
Thank you for any help, I have not had much time finding an answer in the archives o slapd.conf or slapd.bdb man pages. Thanks!
For Sleepycat information, try www.sleepycat.com (which I think/hope now redirects you to somewhere Oracle-ish). For OpenLDAP information, including upgrading, check the OpenLDAP Administrator's Guide.
Douglas B. Jones wrote:
I noticed the that I am getting a number of bdb logs (log.0000000000 .. 210) so far for one db. What is the proper procedure for consolidating these with openldap while keeping the server process running. We have version 2.3.27, but plan on upgrading to 2.3.33.
http://www.openldap.org/faq/data/cache/738.html
I think the links to the DerkeleyDB docs may be out of date now that SleepyCat has been acquired by Oracle. Your best bet is just to look in the local copy of the BDB docs that are included with your BDB installation.
It would probably be a good idea for somebody to go through and update the BDB doc links in the FAQ. The new docs start here http://www.oracle.com/technology/documentation/berkeley-db/db/index.html
The second question: is the best way to migrate from one ldap version to another to slapcat from the old one and the slapadd to the new one? I realize if I do this way, I would in essence have an answer for the first question, but the first one I was wondering from a live point of view.
Yes, but you don't need to do a migration for simple patch updates. I.e., all 2.3.xx releases use the same database format so migration is unnecessary.
Thank you for any help, I have not had much time finding an answer in the archives o slapd.conf or slapd.bdb man pages. Thanks!
--On Tuesday, January 30, 2007 8:22 PM -0500 "Douglas B. Jones" douglas@gpc.edu wrote:
I noticed the that I am getting a number of bdb logs (log.0000000000 .. 210) so far for one db. What is the proper procedure for consolidating these with openldap while keeping the server process running. We have version 2.3.27, but plan on upgrading to 2.3.33.
See the options for DB_CONFIG. In particular:
set_flags DB_LOG_AUTOREMOVE
The second question: is the best way to migrate from one ldap version to another to slapcat from the old one and the slapadd to the new one? I realize if I do this way, I would in essence have an answer for the first question, but the first one I was wondering from a live point of view.
There's no reason to slapcat/slapadd between minor patch levels (2.3.27->2.3.33). All OpenLDAP releases so far have required slapcat/slapadd between major revisions (2.2->2.3, etc). Same thing if you change versions of BDB (4.2 -> 4.4 for example).
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
openldap-software@openldap.org
-
Aaron Richton -
Dave Horsfall -
Douglas B. Jones -
Howard Chu -
Quanah Gibson-Mount