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

Материал из GedeminWiki
(Различия между версиями)
Перейти к: навигация, поиск
(Критерий идентичности баз данных)
(Вопросы)
 
(не показаны 39 промежуточных версий 1 участника)
Строка 1: Строка 1:
Мы будем рассматривать вариант мультинаправленной асинхронной дельта репликации в топографии "звезда".
+
Мы будем рассматривать вариант мультинаправленной асинхронной дельта репликации в топографии "звезда", опираясь на принципы взаимодействия, описанные в статье [[Двунаправленная репликация между двумя базами (постановка)|"Двунаправленная репликация между двумя базами"]].
  
 
http://gsbelarus.com/gs/images/gs/2009/repl_1.png
 
http://gsbelarus.com/gs/images/gs/2009/repl_1.png
Строка 7: Строка 7:
 
Совокупность всех УБД и ЦБД, включенных в схему репликации, называется '''Распределенной базой данных''' (РБД).
 
Совокупность всех УБД и ЦБД, включенных в схему репликации, называется '''Распределенной базой данных''' (РБД).
  
Циркуляция изменений в рамках распределенной базы данных происходит внутри т.н. '''доменов'''. Домен может состоять только из ЦБД, или ЦБД и одной или нескольких УБД. Каждый объект может принадлежать одному или нескольким доменам одновременно. В РБД одновременно может существовать неограниченное количество доменов.
+
=== Домены ===
  
На рисунке ниже показана РБД с двумя доменами. Согласно представленной схеме, если некоторый объект принадлежит только "Домену 1", то его изменения, сделанные на УБД1, будут переданы (реплицированы) на ЦБД и УБД3, но не попадут на УБД2, так как она не входит в "Домен 1". Аналогично, изменения объекта из "Домена 2" будут передаваться только между УБД2 и ЦБД.
+
Циркуляция изменений в рамках распределенной базы данных происходит внутри т.н. '''доменов'''. Домен может состоять только из ЦБД, или ЦБД и одной или нескольких УБД. В РБД одновременно может существовать неограниченное количество доменов.
 +
 
 +
Каждый объект может принадлежать только одному домену. Объекты, явно не принадлежащие ни одному из доменов, реплицируются по всей РБД. Т.е. можно говорить что такие объекты принадлежит некоему '''глобальному домену''', который существует изначально и покрывает всю РБД.
 +
 
 +
На рисунке ниже показана РБД с двумя доменами. Согласно представленной схеме, если некоторый объект принадлежит "Домену 1", то его изменения, сделанные на УБД1, будут переданы (реплицированы) на ЦБД и УБД3, но не попадут на УБД2, так как она не входит в "Домен 1". Аналогично, изменения объекта из "Домена 2" будут передаваться только между УБД2 и ЦБД.
  
 
http://gsbelarus.com/gs/images/gs/2009/repl_2.png
 
http://gsbelarus.com/gs/images/gs/2009/repl_2.png
  
Принадлежность объекта домену может устанавливаться только на основании его класса (вертикальное разбиение) или класса и принадлежности некоторому множеству (горизонтальное разбиение). Пример вертикального разбиения -- все объекты класса "Компания". Пример горизонтального -- все объекты класса "Компания", входящие в папку "Общие клиенты" справочника контактов.
+
Принадлежность объекта домену может устанавливаться только на основании его класса (вертикальное разбиение) или класса и принадлежности некоторому множеству (горизонтальное разбиение). Пример вертикального разбиения — все объекты класса "Компания". Пример горизонтального — все объекты класса "Компания", входящие в папку "Общие клиенты" справочника контактов.
  
Объекты, не принадлежащие ни одному из доменов, реплицируются по всей РБД. Т.е. можно говорить что такие объекты принадлежит некоему глобальному домену, который существует изначально и покрывает всю РБД.
+
После создания объекта, его принадлежность домену не может изменяться.
  
Мы будем называть '''доменным пространством P''' объекта О объединение всех доменов, которым принадлежит указанный объект.
+
В один момент времени изменение объектов в рамках одного домена возможно только на одной из баз, которая называется '''Активной базой данных домена''' (АБД). Активная база данных в начальный момент времени задается схемой репликации и называется '''Главной базой данных домена''' (ГБД). Статус активности передается по запросу от одной базы данных к другой. ГБД передает статус активности на ограниченный промежуток времени T<sub>a</sub>, по истечении которого ГБД снова становится активной, даже если она не посылала соответствующего запроса.
  
В рамках доменного пространства, в один момент времени, редактирование объекта возможно только на одной базе данных. Такая база данных называется '''активной базой данных''' доменного пространства P (АБД). Активная база данных в начальный момент времени называется '''главной базой данных''' доменного пространства P (ГБД). Статус активной базы передается от ГБД к другой базе данных из Р на ограниченный промежуток времени T<sub>a</sub>.
+
После передачи статуса активности БД становится неактивной. '''Неактивная база даных''' (НБД) функционирует в режиме только для чтения.  
  
Мы будем использовать термин '''база данных''' (БД) в тех случаях, когда для нас не имеет значение является ли указанная база ЦБД или УБД в схеме репликации, имеет ли она статус активной в некотором доменном пространстве P или нет.
+
Мы будем использовать термин '''база данных''' (БД) в тех случаях, когда для нас не имеет значение является ли указанная база ЦБД или УБД в схеме репликации, имеет ли она статус активной или нет.
  
== Состояния объекта в УБД ==
+
Порядок выполнения действий над объектами на исходной базе должен строго сохраняться при переносе. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.
  
Каждый объект в УБД находится в определенном состоянии. В таблице ниже перечислены возможные состояния, а также определены допустимые переходы из одного состояния в другое. Состояние объекта влияет на блокировку действий по его изменению или удалению.
+
= Концептуальная схема =
  
{|border="1" cellpadding="2" cellspacing="0"
+
Отличие от двунаправленной репликации между двумя базами заключается в том, что теперь мы имеем несколько баз и возможно несколько доменов. Внутри каждого домена ведется автономная нумерация изменений. В лог на УБД следует добавить поле привязки объекта к домену. На ЦБД мы будем вести по логу для каждой из УБД. При поступлении изменения с УБД, кроме фиксации состояния R в '''ее логе''' на ЦБД, одновременно формируются записи состояния L в логах остальных баз, принадлежащих домену. Только тогда, когда эти записи перейдут в соcтоние C, на исходную базу будет послано подтверждение о передаче объекта.
|+
+
!Состояние
+
!Описание
+
!Блокировка
+
!Переход
+
|-
+
|I
+
|Каждый объект, который существовал до настройки схемы репликации .е. до создания УБД на основе изначально существовавшей ЦБД), имеет состояние I. В начальный момент времени такой объект присутствует как в УБД, так и в ЦБД.
+
|Нет
+
|L
+
|-
+
|L
+
|Изменение объекта занесено в лог. Используется для информирования системы о необходимости отсылки сообщения '''"Передача объекта"''' на ЦБД.
+
|Объект в состоянии L может быть изменен только в том случае, если после него в логе нет никаких других записей. Последовательные изменения (в смысле порядка записей в логе) одного и того же объекта допускаются.
+
|S, B
+
|-
+
|B
+
|Используется для остановки процесса передачи данных на ЦБД. При обработке объекта в состоянии B, процесс формирования сообщений останавливается с уведомлением пользователя о том, какая именно запись вызвала остановку.
+
|Аналогично состоянию L.
+
|L
+
|-
+
|S
+
|Объект был отослан на ЦБД.
+
|Аналогично состоянию L.
+
|C
+
|-
+
|C
+
|Изменение объекта успешно записано в ЦБД.  
+
|Нет
+
|L
+
|}
+
  
== Лог изменений УБД ==
+
= Реализация =
  
Фиксирование изменений состояния объекта осуществляется в логе на УБД, который заполняется триггерами и содержит:
+
== Метаданные ==
  
* целочисленный порядковый номер изменения (начиная с единицы),
+
=== Типы данных ===
* идентификатор объекта,
+
* тип объекта,
+
* вид операции (создание, изменение, удаление),
+
* состояние объекта,
+
* дата и время изменения состояния.
+
  
В дальнейшем, символом N мы будем обозначать номер изменения, а символом М -- максимальный номер изменения в логе. М принимается равным нулю, если лог пуст.
+
Состояние объекта:
 +
 +
  /* в основном логе */
 +
  CREATE DOMAIN rp2_dstate AS CHAR(1)
 +
    CHECK(VALUE IN ('L', 'B', 'S', 'F'));
 +
 +
  /* в архивном логе */
 +
  CREATE DOMAIN rp2_dstate_arch AS CHAR(1)
 +
    CHECK(VALUE IN ('I', 'C', 'R'));
  
== Состояние базы данных ==
+
Типы операций:
  
Мы будем называть целое число S состоянием базы данных. Если S = М, значит все изменения переданы на ЦБД. Если S < M, -- необходимо осуществить передачу. Ситуация, когда S > M означает серьезный сбой в данных репликации, нарушение логической целостности.
+
  CREATE DOMAIN rp2_doptype AS CHAR(1)
 +
    CHECK(VALUE IN ('I', 'U', 'D'))
  
В начальный момент времени:
+
=== Таблицы УБД ===
  
   S = M = 0
+
   CREATE TABLE rp2_rlog (
 +
    domainkey
 +
    rec_num
 +
    obj_id UNIQUE
 +
    obj_class
 +
    obj_subtype
 +
    obj_table
 +
    obj_state
 +
    obj_operation
 +
    logged
  
Базы данных А и B находятся в идентичном состоянии, если M<sub>a</sub> = S<sub>b</sub>.
+
    PRIMARY KEY (domainkey, rec_num)
 +
  )
  
Состояние УБД увеличивается на единицу каждый раз, когда подтверждается передача очередного объекта. S<sub>a</sub> равно максимальному номеру записи в логе в состоянии C.
+
  CREATE TABLE rp2_rlog_arch (
 +
    domainkey
 +
    rec_num
 +
    obj_id
 +
    obj_class
 +
    obj_subtype
 +
    obj_table
 +
    obj_state_arch
 +
    obj_operation
 +
    logged
  
Состояние ЦБД увеличивается на единицу каждый раз, когда успешно принимается и записывается в базу очередной объект. S<sub>b</sub> равно максимальному номеру записи в логе в состоянии R.
+
    PRIMARY KEY (domainkey, rec_num)
 +
  )
 +
 
 +
  CREATE TABLE rp2_rdomain (
 +
    domainkey
 +
    expiration
 +
  )
 +
 
 +
  CREATE TABLE rp2_rbase (
 +
    basekey
 +
  )
 +
 
 +
=== Таблицы ЦБД ===
 +
 
 +
Список баз данных, участвующих в схеме репликации:
 +
 
 +
  CREATE TABLE rp2_base (
 +
    id              dintkey,
 +
    name            dname UNIQUE,
 +
    connection_data dtext254,
 +
 
 +
    CONSTRAINT rp2_pk_base_id PRIMARY KEY (id) 
 +
  )
 +
 
 +
Идентификатор ЦБД, таблица хранит максимум одну запись:
 +
 
 +
  CREATE TABLE rp2_main_base (
 +
    id              dintkey,
 +
    lock_rec        dinteger_notnull DEFAULT 1 UNIQUE,
 +
 
 +
    CONSTRAINT rp2_pk_main_base_id PRIMARY KEY (ID),
 +
    CONSTRAINT rp2_fk_main_base_id FOREIGN KEY (ID)
 +
      REFERENCES rp2_base (id)
 +
      ON DELETE CASCADE
 +
      ON UPDATE CASCADE,
 +
    CHECK (lock_rec = 1)
 +
  )
 +
 
 +
Список доменов:
 +
 +
  CREATE TABLE rp2_domain (
 +
    id            dintkey,
 +
    name          dname UNIQUE,
 +
    generator_name dname UNIQUE,
 +
 +
    CONSTRAINT rp2_pk_domain_id PRIMARY KEY  (ID)
 +
  )
 +
 
 +
Принадлежность баз доменам:
 +
 
 +
  CREATE TABLE rp2_domain_base (
 +
    domainkey  dintkey,
 +
    basekey    dintkey,
 +
 +
    CONSTRAINT rp2_pk_domain_base PRIMARY KEY (domainkey, basekey),
 +
    CONSTRAINT rp2_fk_domain_base_basekey FOREIGN KEY (basekey)
 +
      REFERENCES rp2_base (id)
 +
      ON DELETE CASCADE
 +
      ON UPDATE CASCADE,
 +
    CONSTRAINT rp2_fk_domain_base_domainkey FOREIGN KEY (domainkey)
 +
      REFERENCES rp2_domain (id)
 +
      ON DELETE CASCADE
 +
      ON UPDATE CASCADE
 +
  )
 +
 
 +
Принадлежность классов (подмножеств) доменам:
 +
 
 +
  CREATE TABLE rp2_domain_class (
 +
    id        dintkey,
 +
    domainkey  dintkey,
 +
    name      dname,
 +
    classname  dname,
 +
    subtype    VARCHAR(60),
 +
    tablename  dtablename,
 +
    condition  dtext254,
 +
 
 +
    CONSTRAINT rp2_pk_domain_class PRIMARY KEY (id), 
 +
    CONSTRAINT rp2_fk_domain_class_domainkey FOREIGN KEY (domainkey)
 +
      REFERENCES rp2_domain (id)
 +
      ON DELETE CASCADE
 +
      ON UPDATE CASCADE
 +
  )
  
В начальный момент времени базы данных находятся в идентичном состоянии и выполняется равенство:
+
  CREATE TABLE rp2_clog (
 +
    domainkey
 +
    basekey
 +
    rec_num
 +
    obj_id UNIQUE
 +
    obj_class
 +
    obj_subtype
 +
    obj_state
 +
    logged
 
    
 
    
   S<sub>a</sub> = S<sub>b</sub> = М<sub>a</sub> = М<sub>b</sub> = 0
+
    PRIMARY KEY (domainkey, basekey, rec_num)
 +
   )
  
== Связь в асинхронном режиме ==
+
  CREATE TABLE rp2_clog_arch (
 +
    basekey
 +
    rec_num
 +
    obj_id
 +
    obj_class
 +
    obj_subtype
 +
    obj_state_arch
 +
    logged
 +
  )
  
В том случае, если при обмене данными между УБД и ЦБД нет постоянного канала связи, мы будем использовать следующие параметры:
+
=== Контроль активности БД ===
  T<sub>r</sub> -- Допустимое время ожидания ответа на посланное сообщение.
+
  T<sub>s</sub> -- Время простоя ЦБД с момента обработки последнего сообщения до отсылки запроса о состоянии УБД.
+
  T<sub>i</sub> -- Период с которым УБД осуществляет проверку очереди сообщений и отсылку изменений на ЦБД.
+
  
== Критерий идентичности УБД и ЦБД в асинхронном режиме ==
+
== Организация пользовательского интерфейса ==
  
УБД знает о том, что она идентична ЦБД, если S<sub>a</sub>=M<sub>a</sub>. Т.е. нет объектов в состоянии L, B или S.
+
В начальный момент времени мы имеем одну базу данных. В будущей схеме репликации эта база будет являться ЦБД.
 +
 +
# Мы начинаем с определения списка баз.  
 +
# Определяем список доменов и распределяем базы по доменам.
 +
# Далее, распределяем классы по доменам.
 +
# Создаем файлы УБД для распределения их по филиалам.
 +
# Создаем метаданные ЦБД.
  
ЦБД знает о том, что она идентичная УБД, если получено сообщение '''"Состояние УБД"''' (ответ на сообщение '''"Запрос состояния УБД"''') из которого следует что M<sub>a</sub>=S<sub>b</sub>.
+
= Вопросы =
  
=== Передача статуса активной базы данных ===
+
# Как на УБД будет хранится статус активности для каждого домена?
 +
# Как на ЦБД будет хранится статус активности для каждого домена?
 +
# Как определяется принадлежность конкретного объекта домену?
 +
# Как будут распространятся изменения через ЦБД до всех УБД, входящих в домен?
 +
# Как осуществляется нумерация изменений в рамках каждого домена?
 +
# Как осуществляется репликация элементов множеств?
  
 +
= Примечания =
  
 +
<references />
  
 
[[Category:Постановка]]
 
[[Category:Постановка]]

Текущая версия на 21:23, 20 сентября 2009

Мы будем рассматривать вариант мультинаправленной асинхронной дельта репликации в топографии "звезда", опираясь на принципы взаимодействия, описанные в статье "Двунаправленная репликация между двумя базами".

repl_1.png

Как видно на представленном рисунке, несколько Удаленных баз данных (УБД) обмениваются данными с одной Центральной базой данных (ЦБД). Изменение данных может осуществляться как на УБД, так и на ЦБД. Передача изменений напрямую от одной УБД к другой, минуя ЦБД, невозможна.

Совокупность всех УБД и ЦБД, включенных в схему репликации, называется Распределенной базой данных (РБД).

[править] Домены

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

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

На рисунке ниже показана РБД с двумя доменами. Согласно представленной схеме, если некоторый объект принадлежит "Домену 1", то его изменения, сделанные на УБД1, будут переданы (реплицированы) на ЦБД и УБД3, но не попадут на УБД2, так как она не входит в "Домен 1". Аналогично, изменения объекта из "Домена 2" будут передаваться только между УБД2 и ЦБД.

repl_2.png

Принадлежность объекта домену может устанавливаться только на основании его класса (вертикальное разбиение) или класса и принадлежности некоторому множеству (горизонтальное разбиение). Пример вертикального разбиения — все объекты класса "Компания". Пример горизонтального — все объекты класса "Компания", входящие в папку "Общие клиенты" справочника контактов.

После создания объекта, его принадлежность домену не может изменяться.

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

После передачи статуса активности БД становится неактивной. Неактивная база даных (НБД) функционирует в режиме только для чтения.

Мы будем использовать термин база данных (БД) в тех случаях, когда для нас не имеет значение является ли указанная база ЦБД или УБД в схеме репликации, имеет ли она статус активной или нет.

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

[править] Концептуальная схема

Отличие от двунаправленной репликации между двумя базами заключается в том, что теперь мы имеем несколько баз и возможно несколько доменов. Внутри каждого домена ведется автономная нумерация изменений. В лог на УБД следует добавить поле привязки объекта к домену. На ЦБД мы будем вести по логу для каждой из УБД. При поступлении изменения с УБД, кроме фиксации состояния R в ее логе на ЦБД, одновременно формируются записи состояния L в логах остальных баз, принадлежащих домену. Только тогда, когда эти записи перейдут в соcтоние C, на исходную базу будет послано подтверждение о передаче объекта.

[править] Реализация

[править] Метаданные

[править] Типы данных

Состояние объекта:

 /* в основном логе */
 CREATE DOMAIN rp2_dstate AS CHAR(1) 
   CHECK(VALUE IN ('L', 'B', 'S', 'F'));

 /* в архивном логе */
 CREATE DOMAIN rp2_dstate_arch AS CHAR(1) 
   CHECK(VALUE IN ('I', 'C', 'R'));

Типы операций:

 CREATE DOMAIN rp2_doptype AS CHAR(1) 
   CHECK(VALUE IN ('I', 'U', 'D'))

[править] Таблицы УБД

 CREATE TABLE rp2_rlog (
   domainkey
   rec_num
   obj_id UNIQUE
   obj_class
   obj_subtype 
   obj_table
   obj_state
   obj_operation
   logged
   PRIMARY KEY (domainkey, rec_num)
 )
 CREATE TABLE rp2_rlog_arch (
   domainkey
   rec_num
   obj_id
   obj_class
   obj_subtype 
   obj_table
   obj_state_arch
   obj_operation
   logged
   PRIMARY KEY (domainkey, rec_num)
 )
 CREATE TABLE rp2_rdomain (
   domainkey
   expiration
 )
 CREATE TABLE rp2_rbase (
   basekey
 )

[править] Таблицы ЦБД

Список баз данных, участвующих в схеме репликации:

 CREATE TABLE rp2_base (
   id              dintkey,
   name            dname UNIQUE,
   connection_data dtext254,
 
   CONSTRAINT rp2_pk_base_id PRIMARY KEY (id)  
 )

Идентификатор ЦБД, таблица хранит максимум одну запись:

 CREATE TABLE rp2_main_base (
   id              dintkey,
   lock_rec        dinteger_notnull DEFAULT 1 UNIQUE,
 
   CONSTRAINT rp2_pk_main_base_id PRIMARY KEY (ID),
   CONSTRAINT rp2_fk_main_base_id FOREIGN KEY (ID)
     REFERENCES rp2_base (id)
     ON DELETE CASCADE
     ON UPDATE CASCADE,
   CHECK (lock_rec = 1)
 )

Список доменов:

 CREATE TABLE rp2_domain (
   id             dintkey,
   name           dname UNIQUE,
   generator_name dname UNIQUE,

   CONSTRAINT rp2_pk_domain_id PRIMARY KEY  (ID)
 )

Принадлежность баз доменам:

 CREATE TABLE rp2_domain_base (
   domainkey  dintkey,
   basekey    dintkey,

   CONSTRAINT rp2_pk_domain_base PRIMARY KEY (domainkey, basekey),
   CONSTRAINT rp2_fk_domain_base_basekey FOREIGN KEY (basekey)
     REFERENCES rp2_base (id)
     ON DELETE CASCADE
     ON UPDATE CASCADE,
   CONSTRAINT rp2_fk_domain_base_domainkey FOREIGN KEY (domainkey)
     REFERENCES rp2_domain (id)
     ON DELETE CASCADE
     ON UPDATE CASCADE
 )

Принадлежность классов (подмножеств) доменам:

 CREATE TABLE rp2_domain_class (
   id         dintkey,
   domainkey  dintkey,
   name       dname, 
   classname  dname,
   subtype    VARCHAR(60),
   tablename  dtablename,
   condition  dtext254,
 
   CONSTRAINT rp2_pk_domain_class PRIMARY KEY (id),  
   CONSTRAINT rp2_fk_domain_class_domainkey FOREIGN KEY (domainkey)
     REFERENCES rp2_domain (id)
     ON DELETE CASCADE
     ON UPDATE CASCADE
 )
 CREATE TABLE rp2_clog (
   domainkey
   basekey
   rec_num
   obj_id UNIQUE
   obj_class
   obj_subtype 
   obj_state
   logged
 
   PRIMARY KEY (domainkey, basekey, rec_num)
 )
 CREATE TABLE rp2_clog_arch (
   basekey
   rec_num
   obj_id
   obj_class
   obj_subtype 
   obj_state_arch
   logged
 )

[править] Контроль активности БД

[править] Организация пользовательского интерфейса

В начальный момент времени мы имеем одну базу данных. В будущей схеме репликации эта база будет являться ЦБД.

  1. Мы начинаем с определения списка баз.
  2. Определяем список доменов и распределяем базы по доменам.
  3. Далее, распределяем классы по доменам.
  4. Создаем файлы УБД для распределения их по филиалам.
  5. Создаем метаданные ЦБД.

[править] Вопросы

  1. Как на УБД будет хранится статус активности для каждого домена?
  2. Как на ЦБД будет хранится статус активности для каждого домена?
  3. Как определяется принадлежность конкретного объекта домену?
  4. Как будут распространятся изменения через ЦБД до всех УБД, входящих в домен?
  5. Как осуществляется нумерация изменений в рамках каждого домена?
  6. Как осуществляется репликация элементов множеств?

[править] Примечания

Персональные инструменты
Пространства имён

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