Основные понятия

Система резервирования

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

Сервер резервирования

Сервер резервирования – компьютер системы резервирования, предназначенный для работы в составе системы резервирования, на котором функционирует программа управления server.

Компьютер системы резервирования

Компьютер системы резервирования – компьютер, предназначенный для выполнения функций главного/резервного сервера системы резервирования.

Узел системы резервирования

Узел системы резервирования – точка подключения к локальной сети, имеющая уникальный сетевой адрес и указанная в файле сетевой конфигурации системы резервирования nodetab. Физически один компьютер может быть подключен к нескольким линиям связи через разные разъемы с разными сетевыми адресами. В данном случае система резервирования на этом компьютере будет иметь несколько узлов сети. В файле сетевой конфигурации nodetab, используемом системой резервирования, должны указываться узлы системы резервирования.

Программа управления

Программа управления – программа server, запускаемая на каждом компьютере системы резервирования. Предназначена для выполнения главным/резервным сервером функций сервера системы резервирования при его взаимодействии с программами управления на других серверах системы резервирования.

Главный сервер

Главный сервер – сервер резервирования, на котором запущено ядро СУБД ЛИНТЕР, работающее с клиентскими приложениями.

Резервный сервер

Резервный сервер – сервер резервирования, на котором поддерживается копия рабочей БД главного сервера.

Актуальная БД

Актуальная БД – БД, с которой работали клиентские приложения (в режиме главного сервера), или полученная с главного сервера на резервный в данном сеансе работы управляющей программы, т.е. актуальная БД – эта база данных на главном или резервном сервере, которая изменялась или могла быть изменена после запуска системы резервирования. Резервная БД может стать актуальной только в результате копирования актуальной рабочей БД.

Рабочая БД

Для главного сервера – это БД, с которой работает ядро СУБД ЛИНТЕР (и, соответственно, клиентские приложения).

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

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

Архивная БД

БД, которая не является рабочей. Служит для хранения копии рабочей БД на главном/резервном сервере резервирования. Архивная БД располагается в архивном каталоге.

Местоположение архивной БД определяется при старте системы резервирования (см. описание ключа /pathtoarc).

Для задания пути к БД необходимо использовать абсолютные пути.

Архивный каталог

Каталог для хранения архивной БД.

Рабочий каталог

Каталог для хранения рабочей БД.

Архивный файл БД

Упакованная в один файл копия архивной БД, созданная с помощью внешней программы архивирования файлов (zip, tar, gz, bzip2).

Состояние сервера резервирования

Состояние сервера резервирования – возможное (с точки зрения системы резервирования) логическое состояние сервера резервирования.

Состояние сервера резервирования Характеристика состояния
UNDEFINED 

Состояние после запуска на компьютере сервера резервирования (до ранжирования серверов).

В этом состоянии происходит чтение предыдущих состояний рабочей и архивной БД данного сервера резервирования, передача состояния БД другим серверам системы резервирования и подготовка к выбору MONO-сервера.

MONO 

Главный сервер в одномашинном режиме.

В MONO-состояние сервер переходит в следующих случаях:

  • при старте не было обнаружено других серверов за период опроса сети;

  • при старте группы серверов данный сервер оказался наиболее подходящим по времени или по состоянию системного журнала (в этом случае MONO будет лишь промежуточным состоянием перед переходом в MAIN).

При переходе в MONO-состояние сервер проходит через промежуточные состояния:

  • STARTMONO – при переходе из UNDEFINED-состояния (после старта сервера резервирования);

  • SW_TO_MONO – при переходе из SLAVE-состояния.

MAIN 

Главный сервер в многомашинном режиме. В MAIN-состояние сервер переходит из MONO-состояния при подключении хотя бы одного резервного сервера.

SLAVE 

Резервный сервер в состоянии первоначальной загрузки (копирования) БД с главного сервера.

SLAVE_OK 

Первоначальная загрузка (копирование) БД на резервном сервере завершена. Резервный сервер вышел в режим горячего резерва.

SLAVE_WAIT 

Резервный сервер в ожидании готовности главного сервера.

STARTMONO 

Выполняется переход из UNDEFINED-состояния в MONO-состояние.

SW_TO_MONO 

Выполняется переход из SLAVE-состояния в MONO-состояние.

SHUT_DOWN 

Сервер завершает работу.

Во время нахождения сервера в промежуточных состояниях STARTMONO, SW_TO_MONO происходит запуск ядра СУБД ЛИНТЕР и сетевого драйвера сервера dbs_tcp. После успешного запуска этих программ сервер переходит в состояние MONO, в котором остается до тех пор, пока хотя бы один резервный сервер не закончит первоначальное копирование рабочей БД с главного сервера. Как только это произойдет, сервер перейдет из состояния MONO в состояние MAIN. В этом состоянии сервер будет находиться до тех пор, пока активен хотя бы один резервный сервер, выполнивший первоначальное копирование БД.

В это время остальные серверы резервирования должны работать в режиме резервных (SLAVE_OK). До перехода в это состояние сервер сначала попадает в состояние SLAVE_WAIT – состояние ожидания готовности главного сервера. В этом состоянии сервер ждет подтверждения готовности от главного сервера (главный может еще находиться в процессе запуска). Как только главный сервер будет готов, он пришлет разрешение на продолжение работы резервного сервера, и тот перейдет в состояние копирования БД (SLAVE). В SLAVE-состоянии запускается сетевой драйвер клиента dbc_tcp, утилита архивирования lhb в режиме первоначального копирования БД. По завершении первоначального копирования БД запускаются утилита lhb в режиме дозагрузки изменений в файлы системного журнала и ядро СУБД ЛИНТЕР в специальном режиме, которое переносит изменения из системного журнала в БД. После этого сервер переходит в режим SLAVE_OK – режим горячего резерва.

В состояние SHUT_DOWN сервер переходит при получении команды на завершение работы от пользователя или другого сервера по сети, либо сигнала на завершение работы сервера или системы резервирования (завершение работы, инициированное внешними событиями).

Состояние БД

Состояние БД – логическое состояние БД сервера резервирования в момент текущей или предшествующей работы сервера резервирования с данной БД.

Состояние БД Характеристика состояния
UNDEFINED При первом запуске системы резервирования для этой БД (характеризуется отсутствием файла state, который содержит информацию о предыдущем состоянии БД).
MONO БД на главном сервере в одномашинном режиме.
MAIN БД на главном сервере в многомашинном режиме.
SLAVE БД на резервном сервере.
SLAVEFAILER БД на резервном сервере, остановленном из-за ошибки запуска на нём одного из процессов: dbc_tcp, linter, testdb, lhb.
SLAVECRASH БД на резервном сервере, остановленном из-за неудачного копирования БД при старте системы резервирования. БД непригодна для использования. В это состояние БД переходит также при кодах завершения testdb, linter, информирующих о разрушении целостности БД.
MAINFAILER БД на главном сервере, остановленном из-за ошибки запуска на нём одного из процессов – dbs_tcp, linter, lhb.
MAINCRASH БД на главном сервере, остановленном из-за повреждения на нём БД. БД непригодна для использования. Повреждение определяется по соответствующему коду завершения linter.
События в системе резервирования

Информирование пользователей о внутренней жизни системы резервирования и происходящих в ней изменениях выполняется с помощью механизма событий.

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

Список генерируемых программой управления сервером резервирования событий приведен в таблице 1.

Таблица 1. Список событий системы резервирования
Мнемоника событияОписание событияДополнительное условие
UNDEFINED Определение состояния запущенного сервера. 
SERVEREXIT Программа управления сервером завершила свою работу. 
MONO Сервер стал главным сервером. Резервных серверов нет. 
MAIN К главному серверу подключился первый резервный. 
SLAVE На резервном сервере идет первоначальное скачивание данных. 
SLAVE_WAIT Резервный сервер ждет подтверждения готовности главного сервера. 
SLAVE_OK Резервный сервер перешел в состояние готовности (горячего резерва). 
SW_TO_MONO Резервный сервер начал процесс перехода в состояние главного сервера. 
SHUT_DOWN Управляющая программа сервера приступила к завершению своей работы. Останов инициирован внешними командами. 
SLAVEFAILER Работа управляющей программы резервного сервера завершена из-за ошибки запуска на нем одного из процессов. 
SLAVECRASH Работа управляющей программы резервного сервера завершена при старте системы резервирования из-за ошибки при скачивании БД с главного сервера. 
MAINFAILER Работа управляющей программы главного сервера завершена из-за ошибки запуска на нем одного из процессов. 
MAINCRASH Работа управляющей программы главного сервера завершена из-за повреждения БД. 
STARTMONO Сервер начал переход из UNDEFINED-состояния в MONO-состояние. 
STOPPED Управляющая программа сервера остановлена. 
END_STATUSЗарезервировано. 
WAIT_OLDER Сервер начал переход к ожиданию готовности главного сервера для дальнейшего перехода в состояние резервного сервера. 
NOT_FOUND Истек тайм-аут прослушивания сети при старте. Статус серверу (главный/резервный) пока не назначен. 
NOT_SHUT_DOWN Сервер проигнорировал команду на обмен состояния или останов по причине своей неготовности (запрещен останов главного или резервного сервера, если процесс первоначального скачивания БД не закончен). 
SERVERRESTARTВыполнен перезапуск управляющей программы server. Зарезервировано (используется для совместимости с предыдущими версиями системы резервирования).  
E_PROCESS_STARTНа сервере стартовал процесс.Только при наличии ключа /altstproc
E_PROCESS_EXITНа сервере завершился процесс.Только при наличии ключа /altstproc
E_SHUT_COMMANDПолучена команда на завершение работы управляющей программы всех серверов.Только при наличии ключа /altstproc
E_STOP_COMMANDСервер получил команду на останов своей работы.Только при наличии ключа /altstproc
E_NET_INFOПроизошло изменение состояния одного из серверов или узлов.Только при наличии ключей /watchnet, /altstproc
E_TIME_CHANGEСистемное время на сервере переведено.Только при одновременном наличии ключа /tclog
E_SERVER_TIME_DIFFВыявлена разность времени между данным сервером и одним из других серверов.Только при наличии ключа /tclog
W_DEADLOCK Ядро СУБД ЛИНТЕР перестало реагировать на запросы системы резервирования (зависло).Только при наличии ключа /altstproc
E_TESTDB Начало или окончание процедуры тестирования БД. 
A_SLAVE_OK Главный сервер получил уведомление о готовности резервного сервера. 
A_SHUT_DOWNЗарезервировано. 
A_STOPPED Резервный сервер получил уведомление о том, что главному серверу подана команда на останов. 

Тестовые пакеты

Тестовые пакеты – небольшие блоки данных, посылаемые управляющими программами системы резервирования по локальной сети для мониторинга состояния линий связи и серверов системы резервирования. Каждый тестовый пакет, посланный сервером-источником, предполагает получение ответа от сервера-получателя в течение определенного интервала времени (тайм-аута).

Интервал посылки тестовых пакетов задает «тактовую частоту», на основе которой в системе резервирования выполняются все временные операции. Например, если интервал посылки тестовых пакетов равен 3 сек., а интервал посылки тестовых запросов к ядру СУБД ЛИНТЕР – 2 сек., то реально посылка тестовых запросов будет выполняться с периодом 3 сек.

Идентификатор сервера резервирования

Идентификатор сервера резервирования – уникальное (в пределах системы резервирования) внутреннее 128 битное значение. Идентификатор формируется на основе IP-адреса компьютера, его сетевого имени, случайного числа и, возможно, значения ключа /prior командной строки запуска сервера резервирования.

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

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

На основании идентификатора определяются и собственные узлы сервера резервирования (идентификатор узла совпадает со сгенерированным идентификатором).

Старший сервер

Старший сервер – сервер резервирования, на который возложена функция разрешения конфликтов при конкуренции за выполнение операций, как правило, при старте системы резервирования (когда все компьютеры равны).

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

Узел по умолчанию

Узел удаленного сервера, к которому удалось установить соединение раньше других узлов этого сервера, назначается узлом по умолчанию для удаленного сервера. По линии связи, соединенной с этим узлом, будет осуществляться сетевой обмен, передаваться и приниматься данные. Остальные линии связи, ассоциированные с другими узлами данного сервера, назначаются запасными. Периодически все линии связи тестируются на целостность путем посылки тестовых пакетов.