Доступные версии документации

Горячее архивирование – основа системы резервирования

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

Журнал устроен таким образом, что данные в него помещаются только в конец. Относительное постоянство размера журнала обеспечивается хранением нескольких файлов журнала, размер каждого из которых ограничен. Старые файлы журнала (с уже обработанными транзакциями, данные которых уже внесены в таблицы БД), удаляются. В случае длинной транзакции количество файлов журнала временно увеличивается.

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

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

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

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

Расширением горячего архивирования является непрерывный процесс архивирования. В этом случае после архивирования последних добавленных в системный журнал данных утилита lhb не завершает своей работы, а ожидает следующих изменений, которые также добавляются в архив, что обеспечивает механизм непрерывного горячего архивирования.

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

  1. данные при архивировании накапливаются в одном файле – архиве БД, который позже разворачивается в файлы таблиц БД и системного журнала СУБД. Разворачивание архива требует времени, что, несомненно, снижает скорость перехода системы резервирования в состояние готовности после сбоя главного сервера;

  2. данные могут накапливаться в системном журнале в течение продолжительного времени, поэтому и «докат» также отнимает продолжительное время (часто гораздо большее, чем разворачивание архива), что также снижает время перехода системы в состояние готовности;

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

Для устранения перечисленных недостатков используются особые режимы работы утилиты архивирования lhb и ядра СУБД ЛИНТЕР, а именно:

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

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

  3. кроме того, поскольку ядро СУБД обрабатывает вновь поступившие данные системного журнала и переносит накопленные изменения в таблицы БД, то обработанные файлы журнала, не содержащие не сохраненные в БД транзакции, могут быть удалены. Это также выполняет ядро СУБД в специальном режиме, устраняя последний недостаток.

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

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

В стационарном режиме движение изменяемых данных выглядит следующим образом:

  • приложение путем отправки SQL-запроса модифицирует БД главного сервера системы резервирования;

  • при модификации данных изменяются файлы таблиц БД и файлы системного журнала, причем в системный журнал они добавляются всегда в конец;

  • утилита lhb, запущенная на резервном сервере, получает добавленные в системный журнал данные и сохраняет их в копию файлов системного журнала в БД на резервном сервере;

  • утилита lhb получает данные с помощью сетевого драйвера сервера dbs_tcp, работающего на главном сервере, и сетевого драйвера клиента dbc_tcp, работающего на резервном сервере;

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

Доступ клиентских приложений к главному серверу резервирования автоматически обеспечивается сетевым драйвером клиента dbc_tcp. Он обращается к одному из нескольких ЛИНТЕР-серверов и проверяет их доступность, производя, при необходимости, перенаправление запросов на доступный сервер.

Заметили ошибку?
Выделите текст и нажмите Ctrl + Enter