Назад | Перейти на главную страницу

LDAP: «Неприемлемый файл журнала» после восстановления базы данных

Мой openldap-2.4.21 сервер умер, поэтому я проверил сообщения системного журнала и нашел журналы, сообщающие о повреждении базы данных, которую я попытался исправить, выполнив:

$ /usr/bin/db4.8_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 69 offset 120
Recovery starting from [68][84]
Recovery complete at Mon Nov  7 10:32:54 2011
Maximum transaction ID 80015fb4 Recovery checkpoint [70][28]

После этого я попытался начать slapd который потерпел неудачу из-за Unacceptable log file. Со мной такой проблемы никогда не случалось, db4.*_recover всегда может исправить проблемы. Я знаю, что утилиты ldap были обновлены с db4.7 к db4.8 в последнее время.

$ /etc/init.d/slapd start

$ tail -f /var/log/syslog

Nov  7 10:33:08 server slapd[4083]: @(#) $OpenLDAP: slapd 2.4.21 (Jun  2 2011 19:36:19) $#012#011buildd@allspice:/build/buildd/openldap-2.4.21/debian/build/servers/slapd
Nov  7 10:33:08 server slapd[4084]: hdb_db_open: database "dc=example,dc=org": unclean shutdown detected; attempting recovery.
Nov  7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): Unacceptable log file /var/lib/ldap/log.0000000067: unsupported log version 15
Nov  7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): Invalid log file: log.0000000067: Invalid argument
Nov  7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): PANIC: Invalid argument
Nov  7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): unable to join the environment
Nov  7 10:33:08 server slapd[4084]: hdb_db_open: database "dc=example,dc=org" cannot be recovered, err -30974. Restore from backup!
Nov  7 10:33:08 server slapd[4084]: bdb(dc=example,dc=org): txn_checkpoint interface requires an environment configured for the transaction subsystem
Nov  7 10:33:08 server slapd[4084]: bdb_db_close: database "dc=example,dc=org": txn_checkpoint failed: Invalid argument (22).
Nov  7 10:33:08 server slapd[4084]: backend_startup_one (type=hdb, suffix="dc=example,dc=org"): bi_db_open failed! (-30974)
Nov  7 10:33:08 server slapd[4084]: bdb_db_close: database "dc=example,dc=org": alock_close failed
Nov  7 10:33:08 server slapd[4084]: slapd stopped.

Если я посмотрю на ошибочный файл журнала, он будет создан правильно (тот же размер и правильные разрешения)

$ ls -lh /var/lib/ldap

-rw-r----- 1 openldap openldap  10M 2011-11-07 08:50 log.0000000065
-rw-r----- 1 openldap openldap  10M 2011-11-07 10:12 log.0000000066
-rw-r----- 1 openldap openldap  10M 2011-11-07 10:17 log.0000000067
-rw-r----- 1 openldap openldap  10M 2011-11-07 10:27 log.0000000068
-rw-r----- 1 openldap openldap  10M 2011-11-07 10:27 log.0000000069
-rw------- 1 openldap openldap  30M 2011-10-28 10:30 mail.bdb
-rw------- 1 openldap openldap 2.5M 2011-10-28 10:30 objectClass.bdb
-rw------- 1 openldap openldap  18M 2011-10-28 10:30 sn.bdb
-rw------- 1 openldap openldap 2.2M 2011-10-28 10:30 uid.bdb

Q1: Как я могу решить проблему с недопустимым файлом журнала?

Я пробовал читать файлы журнала, используя db4.8_printlog -h /var/lib/ldap и до сих пор он работал в течение 1 часа, отображая все зарегистрированные транзакции. Я обновлю вопрос, если выдаст ошибку.

Кроме того, когда я запускаю утилиту db_recovery несколько раз подряд БЕЗ перезапуска slapd, я вижу, что последний действительный файл журнала меняется каждый раз, чего я не ожидал.

$ /usr/bin/db*.*_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 71 offset 120
Recovery starting from [70][84]
Recovery complete at Mon Nov  7 10:41:15 2011
Maximum transaction ID 80015fb4 Recovery checkpoint [72][28]

$ /usr/bin/db*.*_recover -v -h /var/lib/ldap/
Finding last valid log LSN: file: 72 offset 120
Recovery starting from [71][84]
Recovery complete at Mon Nov  7 10:43:31 2011
Maximum transaction ID 80015fb4 Recovery checkpoint [73][28]

Q2: Это нормально - видеть, что последний действительный файл журнала изменяется для каждого восстановления базы данных (без использования slapd)?

Лучше использовать утилиты, входящие в пакет OpenLDAP:

$ rpm -ql openldap-servers | grep db_
/usr/sbin/slapd_db_archive
/usr/sbin/slapd_db_checkpoint
/usr/sbin/slapd_db_deadlock
/usr/sbin/slapd_db_dump
/usr/sbin/slapd_db_hotbackup
/usr/sbin/slapd_db_load
/usr/sbin/slapd_db_printlog
/usr/sbin/slapd_db_recover
/usr/sbin/slapd_db_stat
/usr/sbin/slapd_db_upgrade
/usr/sbin/slapd_db_verify

вместо db4-utils пакет:

/usr/bin/db_archive
/usr/bin/db_checkpoint
/usr/bin/db_deadlock
/usr/bin/db_dump
/usr/bin/db_dump185
/usr/bin/db_load
/usr/bin/db_printlog
/usr/bin/db_recover
/usr/bin/db_stat
/usr/bin/db_upgrade
/usr/bin/db_verify

Если у вас есть достаточно времени на небольшой ремонт инфраструктуры, я настоятельно рекомендую следующее:

  • прекратить использовать устаревшие дистрибутивы,
  • начать использовать пакеты из Панель инструментов LDAP проект
  • переключить формат базы данных на MDB: база данных стабильна, работает быстрее и использует половину памяти, чем использовали базы данных на основе BDB

(есть множество новых функций и исправлений ошибок между 2.4.21 и 2.4.39, но стабильная поддержка MDB является одной из наиболее важных функций новых версий)