recovery mode on openldap bdb

[golfreeze]

ส่วนใหญ่เมื่อต้องทำการ recovery berkley database ของ ldap นั้น
จะเกิดจากสาเหตุใหญ่ๆ ที่เจอคือ การไป log file ของตัว ldap ครับแล้วทำให้ start ldap ไม่ขึ้น

###### Step receovery ######
ขั้นแรกคือหยุดการทำงานของ ldap service
#/etc/init.d/ldap stop

เริ่มการ recovery ldap
โดยที่ /var/lib/ldap คือพาธที่เก็บ database ldap ครับ

ถ้า OS running Open-Xchange on SLES 9, ให้ใช้ชุด command ด้านล่าง
#db_recover -h /var/lib/ldap

ถ้าใช้งานเป็นพวก CentOS, Red Hat, ให้ใช้งาน command ตามนี้
#/usr/sbin/slapd_db_recover -h /var/lib/ldap

 (catastrophic recovery mode) จะเพิ่ม step การเชคมากกว่า แบบธรรมดา (ไม่ระบุ option)
#/usr/sbin/slapd_db_recover -c /var/lib/ldap

ถ้าทำการ recovery เสร็จก็ทำการ start ldap service ดูครับผม
#/etc/init.d/ldap start
#crm > resource > start r_slapd
######## Step recovery #########

######## Export , import data #######
ในกรณีที่เรามี ldif file ที่ได้ทำการ backup ไว้นั้น
และทำการ recovery bdb ไม่ได้

#slapcat > /root/ldif_backup.ldif

ขั้นแรกคือหยุดการทำงานของ ldap service
#/etc/init.d/ldap stop

move folder ldap ไปเป็นตัว backup
#cd /var/lib
#mv ldap  ldap.ori

#mkdir ldap
#cp ldap.ori/DB_CONFIG  ldap/.

import ldif file
#ldapadd -l  /root/ldif_backup.ldif

change owner
#chown ldap:ldap -R /var/lib/ldap

start ldap service.
#/etc/init.d/ldap  start

[golfreeze]

Every time users try to access my repository, the process just hangs. Is my repository corrupt?

Your repository is not corrupt, nor is your data lost. If your process accesses the repository directly (mod_dav_svn, svnlook, svnadmin, or if you access a file:// URL), then it's using Berkeley DB to access your data. Berkeley DB is a journaling system, meaning that it logs everything it is about to do before it does so. If your process is interrupted (Control-C, or segfault), then a lockfile is left behind, along with a logfile describing unfinished business. Any other process that attempts to access the database will just hang, waiting for the lockfile to disappear. To awaken your repository, you need to ask Berkeley DB to either finish the work, or rewind the database to a previous state that is known to be consistent. WARNING: You can seriously corrupt your repository if you run recover and another process accesses the repository.

Make absolutely sure you disable all access to the repository before doing this (by shutting down Apache, removing executable permissions from 'svn'). Make sure you run this command as the user that owns and manages the database, and not as root, else it will leave root-owned files in the db directory that cannot be opened by the non-root user who manages the database, which is typically either you or your Apache process. Also be sure to have the correct umask set when you run recover, since failing to do so will lock out users that are in the group allowed to access the repository.

Simply run: svnadmin recover /path/to/repos

Once the command has completed, check the permissions in the db directory of the repository.

Sometimes "svnadmin recover" doesn't work. You may see it give errors like this:

Repository lock acquired. Please wait; recovering the repository may take some time... svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass svnadmin: bdb: PANIC: No such file or directory svnadmin: bdb: PANIC: fatal region error detected; run recovery

or like this:

Repository lock acquired. Please wait; recovering the repository may take some time... svn: DB_RUNRECOVERY: Fatal error, run database recovery svn: bdb: DB_ENV-< log_flush: LSN of 115/802071 past current end-of-log of 115/731460 svn: bdb: Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment [...] svn: bdb: changes: unable to flush page: 0 svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid argument svn: bdb: PANIC: Invalid argument svn: bdb: PANIC: fatal region error detected; run recovery svn: bdb: PANIC: fatal region error detected; run recovery [...]

In that case, try Berkeley DB's native db_recover utility (see db_recover documentation). It usually lives in a "bin/" subdirectory of the Berkeley DB installation, for example if you installed Berkeley DB from source, it might be /usr/local/BerkeleyDB.4.2/bin/db_recover; or on systems where Berkeley DB comes prepackaged it might just be /usr/bin/db_recover. If you have multiple versions of Berkeley DB installed, make sure that the version of db_recover you use matches the version of Berkeley DB with which your repository was created. Run db_recover with the "-c" ("catastrophic recovery") flag. You can also add -v for verbosity, and -h with an argument telling it what db environment to recover (so you don't have to cd into that directory). Thus: db_recover -c -v -h /path/to/repos/db Run this command as the same user who owns the repository, and again, make absolutely sure that no other processes are accessing the repository while you do this (e.g., shut down svnserve or Apache).

[golfreeze]

 slapd_db_recover , The options are as follows:

    -c

    Perform catastrophic recovery instead of normal recovery.

    -e

    Retain the environment after running recovery. This option will rarely be used unless a DB_CONFIG file is present in the home directory. If a DB_CONFIG file is not present, then the regions will be created with default parameter values.

    -f

    Display a message on the standard output showing the percent of recovery completed.

    -h

    Specify a home directory for the database environment; by default, the current working directory is used.

    -P

    Specify an environment password. Although Berkeley DB utilities overwrite password strings as soon as possible, be aware there may be a window of vulnerability on systems where unprivileged users can see command-line arguments or where utilities are not able to overwrite the memory containing the command-line arguments.

    -t

    Recover to the time specified rather than to the most current possible date. The timestamp argument should be in the form [[CC]YY]MMDDhhmm[.SS] where each pair of letters represents the following:

        CC

        The first two digits of the year (the century).

        YY

        The second two digits of the year. If "YY" is specified, but "CC" is not, a value for "YY" between 69 and 99 results in a "CC" value of 19. Otherwise, a "CC" value of 20 is used.

        MM

        The month of the year, from 1 to 12.

        DD

        The day of the month, from 1 to 31.

        hh

        The hour of the day, from 0 to 23.

        mm

        The minute of the hour, from 0 to 59.

        SS

        The second of the minute, from 0 to 61.

    If the "CC" and "YY" letter pairs are not specified, the values default to the current year. If the "SS" letter pair is not specified, the value defaults to 0.

    -V

    Write the library version number to the standard output, and exit.

    -v

    Run in verbose mode.

In the case of catastrophic recovery, an archival copy — or snapshot — of all database files must be restored along with all of the log files written since the database file snapshot was made. (If disk space is a problem, log files may be referenced by symbolic links). For further information on creating a database snapshot, see Archival Procedures. For further information on performing recovery, see Recovery Procedures.

If the failure was not catastrophic, the files present on the system at the time of failure are sufficient to perform recovery.

If log files are missing, db_recover will identify the missing log file(s) and fail, in which case the missing log files need to be restored and recovery performed again.

The db_recover utility uses a Berkeley DB environment (as described for the -h option, the environment variable DB_HOME, or because the utility was run in a directory containing a Berkeley DB environment). In order to avoid environment corruption when using a Berkeley DB environment, db_recover should always be given the chance to detach from the environment and exit gracefully. To cause db_recover to release all environment resources and exit cleanly, send it an interrupt signal (SIGINT).

The db_recover utility exits 0 on success, and >0 if an error occurs.