System Administration is all about maintenance, so it is only fair that we discuss how to correctly maintain an OpenLDAP deployment.
You can use slapcat(8) to generate an LDIF file for each of your slapd(8) back-bdb or back-hdb databases.
slapcat -f slapd.conf -b "dc=example,dc=com"
For back-bdb and back-hdb, this command may be ran while slapd(8) is running.
Berkeley DB log files grow, and the administrator has to deal with it. The procedure is known as log file archival or log file rotation.
Note: The actual log file rotation is handled by the Berkeley DB engine.
Logs of current transactions need to be stored into files so that the database can be recovered in the event of an application crash. Administrators can change the size limit of a single log file (by default 10MB), and have old log files removed automatically, by setting up DB environment (see below). The reason Berkeley DB never deletes any log files by default is that the administrator may wish to backup the log files before removal to make database recovery possible even after a catastrophic failure, such as file system corruption.
Log file names are log.XXXXXXXXXX (X is a digit). By default the log files are located in the BDB backend directory. The db_archive tool knows what log files are used in current transactions, and what are not. Administrators can move unused log files to a backup media, and delete them. To have them removed automatically, place set_flags DB_LOG_AUTOREMOVE directive in DB_CONFIG.
Note: If the log files are removed automatically, recovery after a catastrophic failure is likely to be impossible.
The files with names __db.001, __db.002, etc are just shared memory regions (or whatever). These ARE NOT 'logs', they must be left alone. Don't be afraid of them, they do not grow like logs do.
To understand the db_archive interface, the reader should refer to chapter 9 of the Berkeley DB guide. In particular, the following chapters are recommended:
- Database and log file archival
- Log file removal
- Recovery procedures
- Hot failover
Advanced installations can use special environment settings to fine-tune some Berkeley DB options (change the log file limit, etc). This can be done by using the DB_CONFIG file. This magic file can be created in BDB backend directory set up by slapd.conf(5). More information on this file can be found in File naming chapter. Specific directives can be found in C Interface, look for DB_ENV->set_XXXX calls.
Note: options set in DB_CONFIG file override options set by OpenLDAP. Use them with extreme caution. Do not use them unless You know what You are doing.
The advantages of DB_CONFIG usage can be the following:
- to keep data files and log files on different mediums (i.e. disks) to improve performance and/or reliability;
- to fine-tune some specific options (such as shared memory region sizes);
- to set the log file limit (please read Log file limits before doing this).
To figure out the best-practice BDB backup scenario, the reader is highly recommended to read the whole Chapter 9: Berkeley DB Transactional Data Store Applications. This chapter is a set of small pages with examples in C language. Non-programming people can skip this examples without loss of knowledge.
If you put "checkpoint 1024 5" in slapd.conf (to checkpoint after 1024kb or 5 minutes, for example), this does not checkpoint every 5 minutes as you may think. The explanation from Howard is:
'In OpenLDAP 2.1 and 2.2 the checkpoint directive acts as follows - *when there is a write operation*, and more than <check> minutes have occurred since the last checkpoint, perform the checkpoint. If more than <check> minutes pass after a write without any other write operations occurring, no checkpoint is performed, so it's possible to lose the last write that occurred.''
In other words, a write operation occurring less than "check" minutes after the last checkpoint will not be checkpointed until the next write occurs after "check" minutes have passed since the checkpoint.
This has been modified in 2.3 to indeed checkpoint every so often; in the meantime a workaround is to invoke "db_checkpoint" from a cron script every so often, say 5 minutes.
Exporting to a new system......