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

Версия 16:43, 21 августа 2009

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

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

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

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

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

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

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

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

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

 S = M = 0

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

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

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

 Sa = Sb = Мa = Мb = 0

Состояния записи в логе

Первоначальное состояние записи в логе при регистрации некоторого изменения триггером -- L (Logged). Записи с таким статусом считаются подготовленными к отправке.

Объект может быть заблокирован, состояние B (Blocked). В этом случае он не передается, а так как мы не можем нарушать последовательность выполнения операций на конечной базе данных, то нет смысла передавать операции после заблокированной записи. Пользователь должен быть уведомлен о том, какая именно заблокированная запись вызвала остановку процедуры передачи данных.

Поскольку мы не храним полного состояния объекта в логе, а только ссылку на него, то любое последующее изменение объекта должно быть заблокировано, пока предыдущие изменения не будут успешно переданы на конечную базу данных. Исключение составляют два и более последовательных изменения одного и того же объекта.

На конечной базе данных также ведется лог принятых сообщений. Как и в случае с базой А, каждая запись в логе имеет определенное состояние.

Запись об успешно принятом объекте имеет состояние R (Received).

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

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

База А

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

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

База B

Проверяется наличие сообщений в очереди. При наличии -- сортируются в порядке возрастания номера. Проверяется номер первого сообщения:

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

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

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

Состояния записи в логе

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