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

   1 # $OpenLDAP$
   2 # Copyright 2007 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 MORE
  14
  15 You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8)
  16 back-bdb or back-hdb databases.
  17
  18 >    slapcat -f slapd.conf -b "dc=example,dc=com"
  19
  20 For back-bdb and back-hdb, this command may be ran while slapd(8) is running.
  21
  22 MORE
  23
  24
  25 H2: Berkeley DB Logs
  26
  27 Berkeley DB log files grow, and the administrator has to deal with it. The
  28 procedure is known as log file archival or log file rotation.
  29
  30 Note: The actual log file rotation is handled by the Berkeley DB engine.
  31
  32 Logs of current transactions need to be stored into files so that the database
  33 can be recovered in the event of an application crash. Administrators can change
  34 the size limit of a single log file (by default 10MB), and have old log files
  35 removed automatically, by setting up DB environment (see below). The reason
  36 Berkeley DB never deletes any log files by default is that the administrator
  37 may wish to backup the log files before removal to make database recovery
  38 possible even after a catastrophic failure, such as file system corruption.
  39
  40 Log file names are {{F:log.XXXXXXXXXX}} (X is a digit). By default the log files
  41 are located in the BDB backend directory. The {{F:db_archive}} tool knows what
  42 log files are used in current transactions, and what are not. Administrators can
  43 move unused log files to a backup media, and delete them. To have them removed
  44 automatically, place set_flags {{DB_LOG_AUTOREMOVE}} directive in {{F:DB_CONFIG}}.
  45
  46 Note: If the log files are removed automatically, recovery after a catastrophic
  47 failure is likely to be impossible.
  48
  49 The files with names {{F:__db.001}}, {{F:__db.002}}, etc are just shared memory
  50 regions (or whatever). These ARE NOT 'logs', they must be left alone. Don't be
  51 afraid of them, they do not grow like logs do.
  52
  53 To understand the {{F:db_archive}} interface, the reader should refer to
  54 chapter 9 of the Berkeley DB guide. In particular, the following chapters are
  55 recommended:
  56
  57 * Database and log file archival
  58 * Log file removal
  59 * Recovery procedures
  60 * Hot failover
  61
  62 Advanced installations can use special environment settings to fine-tune some
  63 Berkeley DB options (change the log file limit, etc). This can be done by using
  64 the {{F:DB_CONFIG}} file. This magic file can be created in BDB backend directory
  65 set up by {{slapd.conf}}(5). More information on this file can be found in File
  66 naming chapter. Specific directives can be found in C Interface, look for
  67 {{DB_ENV->set_XXXX}} calls.
  68
  69 Note: options set in {{F:DB_CONFIG}} file override options set by OpenLDAP.
  70 Use them with extreme caution. Do not use them unless You know what You are doing.
  71
  72 The advantages of {{F:DB_CONFIG}} usage can be the following:
  73
  74 * to keep data files and log files on different mediums (i.e. disks) to improve
  75   performance and/or reliability;
  76 * to fine-tune some specific options (such as shared memory region sizes);
  77 * to set the log file limit (please read Log file limits before doing this).
  78
  79 To figure out the best-practice BDB backup scenario, the reader is highly
  80 recommended to read the whole Chapter 9: Berkeley DB Transactional Data Store Applications.
  81 This chapter is a set of small pages with examples in C language. Non-programming
  82 people can skip this examples without loss of knowledge.
  83
  84
  85 H2: Checkpointing
  86
  87 MORE/TIDY
  88
  89 If you put "checkpoint 1024 5" in slapd.conf (to checkpoint after 1024kb or 5 minutes,
  90 for example), this does not checkpoint every 5 minutes as you may think.
  91 The explanation from Howard is:
  92
  93 'In OpenLDAP 2.1 and 2.2 the checkpoint directive acts as follows - *when there
  94 is a write operation*, and more than <check> minutes have occurred since the
  95 last checkpoint, perform the checkpoint. If more than <check> minutes pass after
  96 a write without any other write operations occurring, no checkpoint is performed,
  97 so it's possible to lose the last write that occurred.''
  98
  99 In other words, a write operation occurring less than "check" minutes after the
 100 last checkpoint will not be checkpointed until the next write occurs after "check"
 101 minutes have passed since the checkpoint.
 102
 103 This has been modified in 2.3 to indeed checkpoint every so often; in the meantime
 104 a workaround is to invoke "db_checkpoint" from a cron script every so often, say 5 minutes.
 105
 106 H2: Migration
 107
 108 Exporting to a new system......
 109
 110