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

Материал из GedeminWiki
(Различия между версиями)
Перейти к: навигация, поиск
Строка 2: Строка 2:
  
 
Базы обмениваются между собой сообщениями. Канал связи между базами может быть непостоянным. Т.е. база A может посылать сообщения в тот момент, когда база B недоступна и наоборот. Порядок выполнения действий над объектами на базе A должен сохраняться при переносе на базу B. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.
 
Базы обмениваются между собой сообщениями. Канал связи между базами может быть непостоянным. Т.е. база A может посылать сообщения в тот момент, когда база B недоступна и наоборот. Порядок выполнения действий над объектами на базе A должен сохраняться при переносе на базу B. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.
 +
 +
==== Лог изменений ====
  
 
Фиксирование изменений осуществляется в логе, специальной таблице содержащей:  
 
Фиксирование изменений осуществляется в логе, специальной таблице содержащей:  
 +
 
* порядковый номер изменения (начиная с нуля),
 
* порядковый номер изменения (начиная с нуля),
 
* идентификатор объекта,  
 
* идентификатор объекта,  
Строка 13: Строка 16:
  
 
В дальнейшем, числом М мы будем обозначать максимальный номер записи в логе. М принимается равным нулю, если лог пуст.
 
В дальнейшем, числом М мы будем обозначать максимальный номер записи в логе. М принимается равным нулю, если лог пуст.
 +
 +
==== Состояние базы данных ====
  
 
Мы будем называть целое число S состоянием базы данных. Если S=М, значит все изменения переданы на ЦБД. Если S<M -- необходимо осуществить передачу. Ситуация, когда S>M означает серьезный сбой в данных репликации, нарушение логической целостности.
 
Мы будем называть целое число S состоянием базы данных. Если S=М, значит все изменения переданы на ЦБД. Если S<M -- необходимо осуществить передачу. Ситуация, когда S>M означает серьезный сбой в данных репликации, нарушение логической целостности.
  
В начальный момент времени S=M=0.
+
В начальный момент времени  
 +
 
 +
  S=M=0
  
 
Базы данных А и B находятся в идентичном состоянии, если S<sub>a</sub>=S<sub>b</sub> и очередь сообщений пуста.
 
Базы данных А и B находятся в идентичном состоянии, если S<sub>a</sub>=S<sub>b</sub> и очередь сообщений пуста.
  
В начальный момент времени базы данных находятся в идентичном состоянии:  
+
В начальный момент времени базы данных находятся в идентичном состоянии, т.е. выполняется:  
 
    
 
    
   S<sub>a</sub>=S<sub>b</sub>=М<sub>a</sub>=М<sub>b</sub>=0.
+
   S<sub>a</sub>=S<sub>b</sub>=М<sub>a</sub>=М<sub>b</sub>=0
  
Первоначальное состояние -- L (Logged). Записи с таким статусом считаются подготовленными к отправке.
+
==== Состояния записи в логе ====
 +
 
 +
Первоначальное состояние записи в логе при регистрации некоторого изменения триггером -- L (Logged). Записи с таким статусом считаются подготовленными к отправке.
  
 
Объект может быть заблокирован, состояние B (Blocked). В этом случае он не передается, а так как мы не можем нарушать последовательность выполнения операций на конечной базе данных, то нет смысла передавать операции после заблокированной записи. Пользователь должен быть уведомлен о том, какая именно заблокированная запись вызвала остановку процедуры передачи данных.
 
Объект может быть заблокирован, состояние B (Blocked). В этом случае он не передается, а так как мы не можем нарушать последовательность выполнения операций на конечной базе данных, то нет смысла передавать операции после заблокированной записи. Пользователь должен быть уведомлен о том, какая именно заблокированная запись вызвала остановку процедуры передачи данных.
Строка 33: Строка 42:
  
 
Запись об успешно принятом объекте имеет состояние R (Received).
 
Запись об успешно принятом объекте имеет состояние R (Received).
 +
 +
==== Последовательность обмена сообщениями ====
  
 
Последовательность обмена сообщениями между исходной и конечной базами данных выглядит следующим образом:
 
Последовательность обмена сообщениями между исходной и конечной базами данных выглядит следующим образом:

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

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

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

Содержание

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

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

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

Заполнение лога осуществляется с помощью системы триггеров.

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

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

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

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

 S=M=0

Базы данных А и B находятся в идентичном состоянии, если Sa=Sb и очередь сообщений пуста.

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

 Sa=Sbab=0

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

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

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

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

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

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

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

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

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

Варианты
Действия
Навигация
Инструменты