git.sur5r.net Git - openldap/blob - doc/guide/admin/maintenance.sdf

   1 # $OpenLDAP$
   2 # Copyright 2007-2013 The OpenLDAP Foundation, All Rights Reserved.
   3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
   4
   5 H1: Maintenance
   6
   7 System Administration is all about maintenance, so it is only fair that we
   8 discuss how to correctly maintain an OpenLDAP deployment.
   9
  10
  11 H2: Directory Backups
  12
  13 Backup strategies largely depend on the amount of change in the database
  14 and how much of that change an administrator might be willing to lose in a
  15 catastrophic failure. There are two basic methods that can be used:
  16
  17 1. Backup the Berkeley database itself and periodically back up the transaction
  18 log files:
  19
  20 Berkeley DB produces transaction logs that can be used to reconstruct
  21 changes from a given point in time. For example, if an administrator were willing to only
  22 lose one hour's worth of changes, they could take down the server in
  23 the middle of the night, copy the Berkeley database files offsite, and bring
  24 the server back online. Then, on an hourly basis, they could force a
  25 database checkpoint, capture the log files that have been generated in the
  26 past hour, and copy them offsite. The accumulated log files, in combination
  27 with the previous database backup, could be used with db_recover to
  28 reconstruct the database up to the time the last collection of log files was
  29 copied offsite. This method affords good protection, with minimal space
  30 overhead.
  31
  32
  33 2. Periodically run slapcat and back up the LDIF file:
  34
  35 Slapcat can be run while slapd is active. However, one runs the risk of an
  36 inconsistent database- not from the point of slapd, but from the point of
  37 the applications using LDAP. For example, if a provisioning application
  38 performed tasks that consisted of several LDAP operations, and the slapcat
  39 took place concurrently with those operations, then there might be
  40 inconsistencies in the LDAP database from the point of view of that
  41 provisioning application and applications that depended on it. One must,
  42 therefore, be convinced something like that won't happen. One way to do that
  43 would be to put the database in read-only mode while performing the
  44 slapcat. The other disadvantage of this approach is that the generated LDIF
  45 files can be rather large and the accumulation of the day's backups could
  46 add up to a substantial amount of space.
  47
  48 You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8)
  49 back-bdb or back-hdb databases.
  50
  51 >    slapcat -f slapd.conf -b "dc=example,dc=com"
  52
  53 For back-bdb and back-hdb, this command may be ran while slapd(8) is running.
  54
  55 MORE on actual Berkeley DB backups later covering db_recover etc.
  56
  57 H2: Berkeley DB Logs
  58
  59 Berkeley DB log files grow, and the administrator has to deal with it. The
  60 procedure is known as log file archival or log file rotation.
  61
  62 Note: The actual log file rotation is handled by the Berkeley DB engine.
  63
  64 Logs of current transactions need to be stored into files so that the database
  65 can be recovered in the event of an application crash. Administrators can change
  66 the size limit of a single log file (by default 10MB), and have old log files
  67 removed automatically, by setting up DB environment (see below). The reason
  68 Berkeley DB never deletes any log files by default is that the administrator
  69 may wish to backup the log files before removal to make database recovery
  70 possible even after a catastrophic failure, such as file system corruption.
  71
  72 Log file names are {{F:log.XXXXXXXXXX}} (X is a digit). By default the log files
  73 are located in the BDB backend directory. The {{F:db_archive}} tool knows what
  74 log files are used in current transactions, and what are not. Administrators can
  75 move unused log files to a backup media, and delete them. To have them removed
  76 automatically, place set_flags {{DB_LOG_AUTOREMOVE}} directive in {{F:DB_CONFIG}}.
  77
  78 Note: If the log files are removed automatically, recovery after a catastrophic
  79 failure is likely to be impossible.
  80
  81 The files with names {{F:__db.001}}, {{F:__db.002}}, etc are just shared memory
  82 regions (or whatever). These ARE NOT 'logs', they must be left alone. Don't be
  83 afraid of them, they do not grow like logs do.
  84
  85 To understand the {{F:db_archive}} interface, the reader should refer to
  86 chapter 9 of the Berkeley DB guide. In particular, the following chapters are
  87 recommended:
  88
  89 * Database and log file archival - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/archival.html}}
  90 * Log file removal - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/logfile.html}}
  91 * Recovery procedures - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/recovery.html}}
  92 * Hot failover - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/hotfail.html}}
  93 * Complete list of Berkeley DB flags - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html}}
  94
  95 Advanced installations can use special environment settings to fine-tune some
  96 Berkeley DB options (change the log file limit, etc). This can be done by using
  97 the {{F:DB_CONFIG}} file. This magic file can be created in BDB backend directory
  98 set up by {{slapd.conf}}(5). More information on this file can be found in File
  99 naming chapter. Specific directives can be found in C Interface, look for
 100 {{DB_ENV->set_XXXX}} calls.
 101
 102 Note: options set in {{F:DB_CONFIG}} file override options set by OpenLDAP.
 103 Use them with extreme caution. Do not use them unless You know what You are doing.
 104
 105 The advantages of {{F:DB_CONFIG}} usage can be the following:
 106
 107 * to keep data files and log files on different mediums (i.e. disks) to improve
 108   performance and/or reliability;
 109 * to fine-tune some specific options (such as shared memory region sizes);
 110 * to set the log file limit (please read Log file limits before doing this).
 111
 112 To figure out the best-practice BDB backup scenario, the reader is highly
 113 recommended to read the whole Chapter 9: Berkeley DB Transactional Data Store Applications.
 114 This chapter is a set of small pages with examples in C language. Non-programming
 115 people can skip these examples without loss of knowledge.
 116
 117
 118 H2: Checkpointing
 119
 120 MORE/TIDY
 121
 122 If you put "checkpoint 1024 5" in slapd.conf (to checkpoint after 1024kb or 5 minutes,
 123 for example), this does not checkpoint every 5 minutes as you may think.
 124 The explanation from Howard is:
 125
 126 'In OpenLDAP 2.1 and 2.2 the checkpoint directive acts as follows - *when there
 127 is a write operation*, and more than <check> minutes have occurred since the
 128 last checkpoint, perform the checkpoint. If more than <check> minutes pass after
 129 a write without any other write operations occurring, no checkpoint is performed,
 130 so it's possible to lose the last write that occurred.''
 131
 132 In other words, a write operation occurring less than "check" minutes after the
 133 last checkpoint will not be checkpointed until the next write occurs after "check"
 134 minutes have passed since the checkpoint.
 135
 136 This has been modified in 2.3 to indeed checkpoint every so often; in the meantime
 137 a workaround is to invoke "db_checkpoint" from a cron script every so often, say 5 minutes.
 138
 139 H2: Migration
 140
 141 The simplest steps needed to migrate between versions or upgrade, depending on your deployment
 142 type are:
 143
 144 .{{S: }}
 145 ^{{B: Stop the current server when convenient}}
 146
 147 .{{S: }}
 148 +{{B: slapcat the current data out}}
 149
 150 .{{S: }}
 151 +{{B: Clear out the current data directory (/usr/local/var/openldap-data/) leaving DB_CONFIG in place}}
 152
 153 .{{S: }}
 154 +{{B: Perform the software upgrades}}
 155
 156 .{{S: }}
 157 +{{B: slapadd the exported data back into the directory}}
 158
 159 .{{S: }}
 160 +{{B: Start the server}}
 161
 162 Obviously this doesn't cater for any complicated deployments like {{SECT: MirrorMode}} or {{SECT: N-Way Multi-Master}},
 163 but following the above sections and using either commercial support or community support should help. Also check the
 164 {{SECT: Troubleshooting}} section.
 165
 166