Регулярность тестирования БД резервного сервера (testdb)
Синтаксис
 
/testdb[=
{ < периодическое тестирование >
| < тестирование по расписанию >
| < тестирование по сигналу > }
]
< периодическое тестирование >::=< интервал >
< интервал >::=положительное целое число.  

Значение < интервала > задается в сек.

< тестирование по расписанию >::=см. описание опции < копирование по расписанию > в ключе /arcint.
< тестирование по сигналу >::=SIG< номер сигнала >
< номер сигнала >::=положительное целочисленное значение.
Описание

Задаёт регулярность тестирования рабочей БД резервного сервера. Тестирование БД выполняется утилитой testdb периодически, по расписанию или по сигналу (см. документ «СУБД ЛИНТЕР. Тестирование базы данных»).

Тестирование БД выполняется по следующим правилам:

  1. производится останов ядра СУБД ЛИНТЕР, работающего в специальном режиме на резервном сервере;

  2. из архивного каталога удаляется хранящаяся там БД и на её место копируется рабочая БД резервного сервера. Копирование выполняется в порядке добавления данных – самые последние данные копируются также в последнюю очередь;

  3. производится запуск ядра СУБД ЛИНТЕР в специальном режиме на рабочей БД этого сервера;

  4. в архивном каталоге для только что сделанной копии рабочей БД запускается новый экземпляр ядра СУБД ЛИНТЕР в обычном режиме.

    Повторный запуск ядра СУБД на скопированной БД необходим по следующим причинам:

    • после останова ядра СУБД ЛИНТЕР, работавшего в специальном режиме на резервном сервере, могло продолжаться добавление данных в файлы системного журнала (утилитой lhb);

    • ядро СУБД ЛИНТЕР в специальном режиме на резервном сервере не обрабатывает последний файл системного журнала рабочей БД и не закрывает журнал, поэтому при копировании рабочей БД в архивный каталог журнал остается не до конца обработанным. Запущенная в архивном каталоге СУБД выполняет окончательный докат всех транзакций по системному журналу;

  5. как только второй экземпляр СУБД ЛИНТЕР (на БД в архивном каталоге) выйдет в состояние готовности (докатит записи системного журнала в БД), он принудительно останавливается программой server;

  6. в архивном каталоге запускается утилита тестирования testdb для проверки архивной БД. Вывод testdb направляется в файл testdb.out, который создается в каталоге, задаваемом переменной окружения SERVER_HOME;

  7. в случае обнаружения ошибок в тестируемой БД на консоль и в файл трассировки выводятся соответствующие сообщения.

Если сервер завершает свою работу в режиме резервного сервера, а параллельный процесс тестирования архивной БД или копирования рабочей БД в архивный каталог работают, то он будет немедленно завершен сигналом SIGKILL. В этом случае обработчику событий будет передан соответствующий код события (см. подпункт «Событие E_TESTDB»).

При эксплуатации системы резервирования необходимо учитывать, что ошибки БД диагностируются на резервном сервере, а устранять их необходимо на главном сервере, поскольку БД на резервном сервере является точной копией БД главного сервера. Кроме того, устранение ошибок в БД невозможно без остановки работы всей системы резервирования, поскольку при остановке только главного сервера один из резервных серверов возьмет на себя функции главного сервера, и новые данные уже не попадут в ту БД, с которой будут проводиться профилактические работы. Для устранения ошибок необходимо использовать утилиту testdb.

Результат последнего тестирования БД сохраняется в файле state. Для его просмотра можно использовать ключ /show или утилиту hresctl (srvcmd) (на работающем сервере). Результат тестирования содержит информацию о факте обнаружения ошибок в БД или их отсутствии, и время окончания тестирования БД.

Примечание

Т.к. тестируется копия рабочей БД резервного сервера в архивном каталоге, а последняя является копией рабочей БД главного сервера, то результат тестирования распространяется на все три перечисленные БД.

Если задано периодическое тестирование БД, то утилита testdb будет периодически запускаться на резервном сервере через заданный < интервал > времени после завершения предыдущего тестирования. Тестирование сильно нагружает систему резервирования, поэтому, если время очередного тестирования совпало с повышенными нагрузками на систему резервирования, её производительность может понизиться.

При использовании расписания, если предыдущая операция тестирования не была завершена, новая операция тестирования пропускается.

Для запуска тестирования БД по сигналу рекомендуется использовать сигнал SIGALRM.

В целях безопасности тестирование выполняется только при условии, что БД целиком получена с главного сервера.

Часть операций, задаваемых ключами /arcint и /testdb, совпадают. Если эти ключи заданы одновременно, началось копирование БД, инициированное ключом /arcint, и при этом наступает время тестирования БД, то дополнительная операция копирования отменяется. И наоборот, если началось копирование БД, инициированное ключом /testdb, и при этом наступает время копирования БД по ключу /arcint, то повторное копирование также отменяется. Если при этом совпадении указан еще и ключ /archivate, то тестирование БД начнется только после создания архивного файла архивной БД.

По умолчанию (при отсутствии ключа /testdb) тестирование БД не выполняется, однако, если ключ /testdb задан, но без параметров, то тестирование будет выполняться ежедневно в полночь.

Примеры
-testdb=300
-testdb
-testdb=sig12
/testdb=ATwed0500,sun0300