ЛИНТЕР

Повторный запуск

Повторный запуск системы резервирования (после принудительного останова системы резервирования или после сбоя) аналогичен первоначальному и предполагает выполнение следующих операций:

синхронизацию времени серверов резервирования;
настройку переменных окружения;
запуск программы server на компьютерах системы резервирования.

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

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

/ntab – для указания пути к файлу сетевой конфигурации nodetab;
/pathtodb или переменную окружения SY00 – для указания пути к рабочей БД;
/pathtoarc – для указания пути к файлу архивной БД;
/testint, /tstlimit, /treq, /forceshut – для задания периодичности проверки активности линий связи (определяется как /testint*/tstlimit), максимального времени выполнения пользовательского запроса и максимального времени пересылки не переданных с главного сервера на резервный сервер данных при останове главного сервера;
/pool – для установки размера оперативной памяти, выделяемой для работы ядра СУБД ЛИНТЕР;
/stproc, /pid, /wp – в случае управления работой системы резервирования не администратором системы резервирования, а специальной программой;
/wd – рекомендуется задавать всегда. При управлении системой резервирования из программы может потребоваться указывать также и значение этого ключа;
/nservers – при наличии более одной линии связи у каждого компьютера системы резервирования;
/exchdir – включен по умолчанию. /exchdir=0 не рекомендуется использовать как устаревшее;
/debug – для сохранения протокола работы системы резервирования. В отдельных случаях, например, при возникновении непонятного поведения системы резервирования, необходимо задавать более детальный уровень трассировки.

В случае повторного запуска системы резервирования (т.е. после того, как система резервирования функционировала, а затем её работа по каким-то причинам была остановлена) следует быть осторожным при использовании ключей запуска /nq и /nservers.

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

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

Безопасные способы повторного запуска:

запустить серверы одновременно в полном составе без ключа /nq и задать /nservers=< количеству запускаемых серверов >. При этом система сама произведет ранжирование серверов и запустит сервер со свежей БД как главный;
запустить первым сервер с наиболее свежей БД и, когда он перейдет в режим MONO, запустить остальные серверы системы резервирования.

Для повторного запуска системы резервирования рекомендуется создать скрипт, который выполняет все подготовительные действия и производит запуск управляющей программы.