19. Обслуживание

Системное администрирование - это и есть обслуживание; таким образом, наши рассуждения о том, как правильно обслуживать системы OpenLDAP, вполне закономерны.

19.1. Резервное копирование каталога

Стратегия резервного копирования во многом определяется количеством изменений базы данных, а также тем, насколько большую часть этих изменений администратор готов потерять в случае катастрофического краха системы. Существует два основных подхода:

1. Резервное копирование самой базы данных Berkeley и периодическое резервное копирование файлов журналов транзакций:

Berkeley DB ведёт журналы транзакций, которые могут быть использованы для реконструкции изменений, начиная с заданной точки во времени. Например, если администратора не устраивает потеря изменений больше чем за один час, он может останавливать сервер в ночное время, копировать файлы базы данных Berkeley в надёжное место, и вновь запускать сервер. Затем ежечасно он может принудительно вызывать сброс базы данных в контрольной точке, собирать файлы журнала, созданные за последний час, и копировать их в надёжной место. С помощью инструмента db_recover можно, на основании собранных файлов журнала в сочетании с предыдущей резервной копией базы данных, реконструировать базу данных на момент последнего сбора файлов журнала. Этот подход обеспечивает хорошую сохранность данных с минимальными затратами дискового пространства.

2. Периодический запуск slapcat и резервное копирование LDIF-файла:

Slapcat может быть запущен во время работы slapd. Однако, есть риск возникновения нарушений целостности базы данных, причём не с точки зрения slapd, а с точки зрения приложений, использующих LDAP. Например, если пополняющее каталог приложение выполняет задачи, состоящие из нескольких операций LDAP, и slapcat выполнялся одновременно с этими операциями, то могут произойти нарушения целостности в базе данных LDAP с точки зрения этого приложения и приложений, зависящих от него. Следовательно, нужно убедиться, чтобы подобное не происходило. Один из путей решения - перевод базы данных в режим только для чтения на время выполнения slapcat. Другой недостаток этого подхода состоит в том, что созданные файлы LDIF могут быть довольно большими и накопление ежедневных резервных копий может занять значительный объём дискового пространства.

Можно использовать slapcat(8) для создания отдельных файлов LDIF для каждой из Ваших баз данных back-bdb или back-hdb.

    slapcat -f slapd.conf -b "dc=example,dc=com"

Для back-bdb и back-hdb данная команда может быть выполнена при запущенном slapd(8).

Дополнительная информация о резервном копировании Berkeley DB, включая db_recover и другое, будет позже.

19.2. Журналы Berkeley DB

Файлы журнала Berkeley DB имеют тенденцию разрастаться, и администратору приходится что-то с этим делать. Данная процедура известна как архивирование или ротация файлов журнала.

Примечание: Реальная ротация файлов журнала производится механизмом Berkeley DB.

Журналы текущих транзакций должны сохраняться в файлах для того, чтобы база данных могла быть восстановлена в случае сбоя приложения. Администраторы могут изменить ограничения на размер одного файла журнала (по умолчанию 10MB), и настроить автоматическое удаление старых файлов журнала путём установки окружения базы данных (смотрите ниже). Причиной того, что Berkeley DB по умолчанию никогда не удаляет никаких файлов журнала, является то, что администратор может захотеть сделать резервные копии файлов журнала перед удалением, чтобы была возможность восстановления базы данных даже после катастрофического отказа, такого, как повреждение файловой системы.

Имена файлов журнала - log.XXXXXXXXXX (X - это цифра). По умолчанию файлы журнала размещаются в директории с базой данных. Инструмент db_archive знает, какие файлы журнала используются в текущих транзакциях, а какие нет. Администраторы могут копировать неиспользуемые файлы в надёжное место и удалять их. Чтобы они удалялись автоматически, поместите директиву set_flags DB_LOG_AUTOREMOVE в файл DB_CONFIG.

Примечание: Если файлы журнала удаляются автоматически, восстановление после катастрофического сбоя скорее всего будет невозможно.

Файлы с именами __db.001, __db.002 и т.д. - это просто разделяемые участки памяти (или что-либо ещё). Это НЕ ЖУРНАЛЫ, и они должны быть оставлены в покое. Не переживайте за них, они не разрастаются так, как файлы журналов.

Чтобы понять, как работает интерфейс db_archive, изучите главу 9 руководства Berkeley DB. В частности, рекомендуется ознакомиться со следующими подглавами:

Архивирование баз данных и файлов журнала - http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/archival.html;
Удаление файлов журнала - http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/logfile.html;
Процедура восстановления - http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/recovery.html;
Оперативное устранение отказов - http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/hotfail.html
Полный список флагов Berkeley DB - http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html.

Продвинутые инсталляции могут использовать специальные установки окружения для тонкой настройки некоторых опций Berkeley DB (изменения ограничения размера файлов журнала и т.п.). Это может быть сделано с помощью файла DB_CONFIG. Этот волшебный файл может быть создан в директории с базой данных механизма манипуляции данными BDB, определённой в slapd.conf(5). Более подробную информацию об этом файле можно найти в главе, называемой 'File', руководства Berkeley DB. Конкретные директивы можно найти в интерфейсе C, ищите вызовы DB_ENV->set_XXXX .

Примечание: опции, задаваемые в файле DB_CONFIG, переопределяют опции, заданные в OpenLDAP. Используйте их с большой осторожностью. Если Вы не знаете, что делают эти опции, не используйте их.

Применяя DB_CONFIG, можно получить следующие преимущества:

размещение файлов с данными и файлов журнала на разных носителях (дисках) для повышения производительности и/или надёжности;
тонкая настройка некоторых специфических опций (таких, как размеры разделяемых участков памяти);
настройка ограничений размера файлов журнала (перед тем, как это делать, прочитайте, пожалуйста, главу 'Log file limits' руководства Berkeley DB).

Для выяснения передовой практики резервного копирования BDB настоятельно рекомендуется полностью прочитать главу 9 руководства Berkeley DB: 'Berkeley DB Transactional Data Store Applications' ('Приложения хранения данных с транзакциями Berkeley DB'). Эта глава состоит из набора маленьких страниц с примерами на языке C. Люди, далёкие от программирования, могут пропустить эти примеры без потери необходимых знаний.

19.3. Срабатывание контрольных точек

Если Вы поместили в slapd.conf "checkpoint 1024 5" (то есть, срабатывание контрольной точки после 1024Kb или 5 минут), это не означает, что контрольная точка будет срабатывать каждые пять минут, как Вы могли бы подумать. Howard дал следующие пояснения:

'В OpenLDAP 2.1 и 2.2 директива checkpoint работает следующим образом - *если была операция записи* и с момента срабатывания последней контрольной точки прошло более чем <check> минут, выполняется срабатывание контрольной точки. Если после записи прошло более чем <check> минут без выполнения какой-либо другой операции записи, срабатывание контрольной точки не выполняется; таким образом, существует возможность потерять последнюю произошедшую операцию записи'.

Другими словами, операция записи, произошедшая менее чем через "check" минут после последнего срабатывания контрольной точки, не будет сброшена на диск в контрольной точке, пока следующая операция записи не произойдёт более чем через "check" минут после последнего срабатывания контрольной точки.

В версии 2.3 это было изменено таким образом, чтобы срабатывание действительно происходило так часто, как оно настроено; вариант решения для предыдущих версий - выполнять "db_checkpoint" из cron так часто, как это требуется, скажем, каждые 5 минут.

19.4. Миграция

В зависимости от типа развёртывания Вашего каталога, простейшие шаги, которые необходимо выполнить для миграции между версиями или обновления, могут быть такими:

Перед началом процедуры остановите сервер текущей версии;
Экспортируйте данные каталога с помощью slapcat;
Очистите текущую директорию с данными (/usr/local/var/openldap-data/), оставив DB_CONFIG на месте;
Выполните обновление программного обеспечения;
Импортируйте экспортированные данные обратно в каталог с помощью slapadd;
Запустите сервер.

Очевидно, это не совсем подходит при сложных типах развёртываний, таких как Режим зеркала или Разнонаправленная репликация с несколькими главными серверами, в таких случаях может помочь изучение предыдущих разделов. Кроме того, Вы всегда можете воспользоваться коммерческой поддержкой или поддержкой сообщества. Также посмотрите раздел Устранение неполадок.