Однонаправленная репликация между двумя базами (постановка)

Рассмотрим вариант однонаправленной репликации между двумя базами A и B. Все изменения осуществляются на базе A. База B работает в режиме только для чтения. В дальнейшем, мы будем использовать термины "Удаленная база данных (УБД)" для базы А и "Центральная база данных (ЦБД)" для B.

Базы обмениваются между собой сообщениями. Канал связи между базами может быть непостоянным. Т.е. база A может посылать сообщения в тот момент, когда база B недоступна и наоборот. Порядок выполнения действий над объектами на базе A должен сохраняться при переносе на базу B. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.

Состояния объекта в УБД

Каждый объект в УБД находится в определенном состоянии. В таблице ниже перечислены возможные состояния, а также определены допустимые переходы из одного состояния в другое.

Состояние	Описание	Блокировка	Переход
I	Каждый объект, который существовал до настройки схемы репликации (т.е. до создания УБД на основе изначально существовавшей ЦБД), имеет состояние I. В начальный момент времени такой объект присутствует как в УБД, так и в ЦБД.	Нет	L
L	Изменение объекта занесено в лог. Используется для информирования системы о необходимости отсылки сообщения "Передача объекта" на ЦБД.	Объект в состоянии L может быть изменен только в том случае, если после него в логе нет никаких других записей. Последовательные изменения (в смысле порядка записей в логе) одного и того же объекта допускаются.	S, B
B	Используется для остановки процесса передачи данных на ЦБД. При обработке объекта в состоянии B, процесс формирования сообщений останавливается с уведомлением пользователя о том, какая именно запись вызвала остановку.	Аналогично состоянию L.	L
S	Объект был отослан на ЦБД.	Аналогично состоянию L.	C, F
C	Изменение объекта успешно записано в ЦБД.	Нет	L
F	Изменение объекта не может быть записано в ЦБД. Необходимо срочное вмешательство системного администратораи ручная синхронизация данных УБД и ЦБД.	Объект остается в заблокированном состоянии.	L, С

Лог изменений

Фиксирование изменений осуществляется в логе, который заполняется триггерами и содержит:

• целочисленный порядковый номер изменения (начиная с единицы),
• идентификатор объекта,
• тип объекта,
• вид операции (создание, изменение, удаление),
• состояние записи лога.

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

Состояния объекта в ЦБД

Состояние	Описание	Переход
I	Объект существовал до настройки схемы репликации.	R
R	Объект получен и записан в базу данных.
F	Объект получен, но не может быть записан в базу данных. Необходимо срочное вмешательство системного администратора для ручного разрешения конфликта данных.	R

Состояние базы данных

Мы будем называть целое число S состоянием базы данных. Если S = М, значит все изменения переданы на ЦБД. Если S < M, -- необходимо осуществить передачу. Ситуация, когда S > M означает серьезный сбой в данных репликации, нарушение логической целостности.

В начальный момент времени:

 S = M = 0

Базы данных А и B находятся в идентичном состоянии, если S_a = S_b и очередь сообщений пуста. Поскольку просто физическое отсутствие сообщений в очереди не означает того, что их там не было. То, говорить об идентичности баз мы можем только после того, как ЦБД послала "Запрос состояния УБД" и получила на него ответ.

Состояние базы данных увеличивается на единицу каждый раз, когда подтверждается передача очередного объекта. Фактически, состояние базы данных равно максимальному номеру записи в логе в состоянии C (Confirmed).

В начальный момент времени базы данных находятся в идентичном состоянии, т.е. выполняется:

 Sa = Sb = Мa = Мb = 0

Связь в асинхронном режиме

В том случае, если при обмене данными между УБД и ЦБД нет постоянного канала связи, мы будем следующие параметры:

 Tr -- Допустимое время ожидания ответа на посланное сообщение.
 Ts -- Время простоя системы с момента обработки последнего сообщения до отсылки запроса о состоянии УБД.

Журнал репликации

Журнал используется системным администратором для выявления проблем в репликации данных. В журнал заносятся:

• Предупреждения
• Критические ошибки

Последовательность обмена сообщениями

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

База А

Проверяется очередь сообщений:

1. Очередь сообщений пуста:
   1. Если есть записи в состоянии S и с момента отправки самой первой из них прошло времени больше чем T_r, то ставим в известность системного администратора, а на ЦБД отсылаем сообщение "Запрос подтверждения передачи объекта". В сообщении указываем идентификатор объекта.
   2. Проверяется лог на наличие записей в состоянии L. Для каждой такой записи формируется и посылается отдельное сообщение "Передача объекта". После формирования и успешной отправки сообщения, запись в логе переводится в состояние S (Sent).
2. Если в очереди присутствуют сообщения, группируем их по типу и сортируем внутри группы по порядковому номеру. Обрабатываем последовательно по типам сообщений:
   1. "Подтверждение передачи объекта":
      1. Если номер из сообщения соответствует номеру первого объекта со статусом S, то переводим объект в состояние C. Продолжаем обрабатывать список сообщений.
      2. Если номер из сообщения меньше номера первого объекта со статусом S, то игнорируем такое сообщение. Продолжаем обрабатывать список сообщений. Может информировать сисадмина?
      3. Если номер из сообщения больше номера первого объекта со статусом S, прекращаем дальнейшую обработку сообщений "Подтверждение передачи объекта". Отсылаем на сервер сообщение "Запрос подтверждения передачи объекта". Может выждать время?
   2. "Запрос на передачу объекта".
      1. Если запрашиваемый объкт находится в состоянии S, то передаем его на ЦБД.
      2. Если запрашиваемый объкт находится в состоянии L или C, или вообще отсутствует в списке, то игнорируем сообщение, а системного администратора информируем о ситуации.
   3. "Запрос состояния УБД".

База B

Проверяется наличие сообщений в очереди.

1. Очередь пуста:
   1. Ранее было отправлено сообщение "Запрос состояния УБД":
      1. Если интервал времени на ответ не истек, то продолжаем ожидать.
      2. Интервал времени истек. Информируем системного администратора. Повторяем "Запрос состояния УБД".
   2. Если истек интервал проверки связи и состояния УБД, то отсылаем "Запрос состояния УБД".
2. Очередь не пуста:
   1. ...

1. Если он соответствует ожидаемому, то происходит считывание и обработка сообщения.
2. Если номер первого сообщения в очереди меньше ожидаемого, то просто игнорируем его (удаляем).
3. Если номер первого сообщения в очереди больше ожидаемого, то посылаем запрос на пересылку сообщений с нужными номерами. Останавливаем дальнейшую обработку очереди. Ждем ответа от исходной базы.
4. ...

Запрос состояния УБД

Когда база B хочет узнать текущее состояние синхронизации с базой А, она посылает специальное сообщение "Запрос состояния УБД" и фиксирует время его отправки. Получив данное сообщение, база А действует в соответствии со своим логом. Если он содержит записи, подлежащие отправке, то формируются и посылаются соответствующие сообщения. Непосредственного ответа на "Запрос состояния УБД" в этом случае не отсылается. Если лог не содержит записей для отправки, то формируется специальное сообщение "Состояние УБД", которым передается число S_a. После отсылки запроса База B периодически проверяет свою очередь сообщений. Если в течение заданного тайм-аута в очередь не поступило ни одного ответа от базы А, то системный администратор оповещается о возможном нарушении канала связи или неполадках на УБД. Если поступил ответ "Состояние УБД", то S_a сверяется с S_b. При их равенстве базы данных считаются идентичными (синхронизированными). Если S_a > S_b, то база B отсылает сообщение "Запрос на передачу объекта" с указанием номера S_b + 1. Состояние, когда S_a < S_b, свидетельствует о серьезной рассинхронизации двух баз данных и требует немедленного информирования системного администратора.

"Запрос состояния УБД" отсылается автоматически по истечении заданного интервала времени с момента обработки последнего сообщения от УБД или с момента отправки предыдущего запроса на состояние, на который не поступило ответа.

Структура сообщения

Поле	Описание
Контрольная сумма	Хэш код MD5, который позволяет контролировать целостность полученного сообщения. Рассчитывается по всему потоку данных, включая и заголовок.
Идентификатор УБД
Идентификатор ЦБД
Номер записи в логе
Данные