From: Gavin Henry Date: Sun, 5 Aug 2007 22:18:12 +0000 (+0000) Subject: Merging and amending more FAQ content. X-Git-Tag: OPENLDAP_REL_ENG_2_4_MP~271 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=3a36d3514c3da82e393546ad091702bbb2099ceb;p=openldap Merging and amending more FAQ content. --- diff --git a/doc/guide/admin/maintenance.sdf b/doc/guide/admin/maintenance.sdf index 9514586526..b4160d717a 100644 --- a/doc/guide/admin/maintenance.sdf +++ b/doc/guide/admin/maintenance.sdf @@ -4,15 +4,103 @@ H1: Maintenance -http://www.openldap.org/faq/data/cache/286.html +System Administration is all about maintenance, so it is only fair that we +discuss how to correctly maintain an OpenLDAP deployment. H2: Directory Backups +MORE + +You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8) +back-bdb or back-hdbdatabases. + +> 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. + +MORE + H2: Berkeley DB Logs +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 {{F:log.XXXXXXXXXX}} (X is a digit). By default the log files +are located in the BDB backend directory. The {{F: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 {{F:DB_CONFIG}}. + +Note: If the log files are removed automatically, recovery after a catastrophic +failure is likely to be impossible. + +The files with names {{F:__db.001}}, {{F:__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 {{F: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 {{F: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 {{F: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 {{F: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-prorgamming +people can skip this examples without loss of knowledge. + H2: Checkpointing +MORE/TIDY + +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 minutes have occurred since the +last checkpoint, perform the checkpoint. If more than 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. +