Мультинаправленная репликация между базами (постановка)
SYSDBA (обсуждение | вклад) (→Таблицы УБД) |
SYSDBA (обсуждение | вклад) (→Таблицы УБД) |
||
| Строка 72: | Строка 72: | ||
domainkey | domainkey | ||
expiration | expiration | ||
| + | ) | ||
| + | |||
| + | |||
| + | CREATE TABLE rp2_rbase ( | ||
| + | basekey | ||
) | ) | ||
Версия 19:30, 10 сентября 2009
Мы будем рассматривать вариант мультинаправленной асинхронной дельта репликации в топографии "звезда", опираясь на принципы взаимодействия, описанные в статье "Двунаправленная репликация между двумя базами".
Как видно на представленном рисунке, несколько Удаленных баз данных (УБД) обмениваются данными с одной Центральной базой данных (ЦБД). Изменение данных может осуществляться как на УБД, так и на ЦБД. Передача изменений напрямую от одной УБД к другой, минуя ЦБД, невозможна.
Совокупность всех УБД и ЦБД, включенных в схему репликации, называется Распределенной базой данных (РБД).
Циркуляция изменений в рамках распределенной базы данных происходит внутри т.н. доменов. Домен может состоять только из ЦБД, или ЦБД и одной или нескольких УБД. В РБД одновременно может существовать неограниченное количество доменов.
Каждый объект может принадлежать только одному домену. Объекты, явно не принадлежащие ни одному из доменов, реплицируются по всей РБД. Т.е. можно говорить что такие объекты принадлежит некоему глобальному домену, который существует изначально и покрывает всю РБД.
На рисунке ниже показана РБД с двумя доменами. Согласно представленной схеме, если некоторый объект принадлежит "Домену 1", то его изменения, сделанные на УБД1, будут переданы (реплицированы) на ЦБД и УБД3, но не попадут на УБД2, так как она не входит в "Домен 1". Аналогично, изменения объекта из "Домена 2" будут передаваться только между УБД2 и ЦБД.
Принадлежность объекта домену может устанавливаться только на основании его класса (вертикальное разбиение) или класса и принадлежности некоторому множеству (горизонтальное разбиение). Пример вертикального разбиения -- все объекты класса "Компания". Пример горизонтального -- все объекты класса "Компания", входящие в папку "Общие клиенты" справочника контактов.
В один момент времени изменение объектов возможно только на одной из баз, которая называется Активной базой данных (АБД). Активная база данных в начальный момент времени задается схемой репликации и называется Главной базой данных (ГБД). Статус активности передается по запросу от одной базы данных к другой. ГБД передает статус активности на ограниченный промежуток времени, по истечении которого ГБД снова становится активной, даже если она не посылала соответствующего запроса.
В рамках домена, в один момент времени, редактирование или удаление объекта возможно только на одной базе данных. Такая база данных называется активной базой данных (АБД). Активная база данных в начальный момент времени задается схемой репликации и называется главной базой данных (ГБД). Статус активности передается по запросу от одной базы данных к другой. ГБД передает статус активности на ограниченный промежуток времени — Ta, по истечении которого ГБД снова становится активной, даже если она не посылала соответствующего запроса. После передачи статуса активности БД становится неактивной. Неактивная база даных (НБД) функционирует в режиме только для чтения.
Мы будем использовать термин база данных (БД) в тех случаях, когда для нас не имеет значение является ли указанная база ЦБД или УБД в схеме репликации, имеет ли она статус активной или нет.
Порядок выполнения действий над объектами на исходной базе должен строго сохраняться при переносе. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.
Реализация
Метаданные
Типы данных
Состояние объекта:
/* в основном логе */
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_state logged )
CREATE TABLE rp2_rlog_arch ( domainkey rec_num obj_id obj_class obj_subtype obj_state_arch logged )
CREATE TABLE rp2_rdomain ( domainkey expiration )
CREATE TABLE rp2_rbase ( basekey )
Таблицы ЦБД
Список баз данных, участвующих в схеме репликации:
CREATE TABLE rp2_base ( id name )
Идентификатор ЦБД:
CREATE TABLE rp2_main_base ( id )
Список доменов:
CREATE TABLE rp2_domain ( id name )
Принадлежность баз доменам:
CREATE TABLE rp2_domain_base ( basekey domainkey )
Принадлежность классов (подмножеств) доменам:
CREATE TABLE rp2_domain_class ( domainkey classname subtype tablename condition )
CREATE TABLE rp2_clog ( basekey rec_num obj_id UNIQUE obj_class obj_subtype obj_state logged )
CREATE TABLE rp2_clog_arch ( basekey rec_num obj_id obj_class obj_subtype obj_state_arch logged )
Контроль активности БД
Организация пользовательского интерфейса
В начальный момент времени мы имеем одну базу данных. В будущей схеме репликации эта база будет являться ЦБД.
- Мы начинаем с определения списка доменов.
- Далее, распределяем классы по доменам.
- Определяем список удаленных баз.
- В каждый домен включаем соответствующие удаленные базы.
- Создаем файлы УБД для распределения их по филиалам.
Вопросы
- Как на УБД будет хранится статус активности для каждого домена?
- Как на ЦБД будет хранится статус активности для каждого домена?
- Как определяется принадлежность конкретного объекта домену?
- Как будут распространятся изменения через ЦБД до всех УБД, входящих в домен?
- Как осуществляется нумерация изменений в рамках каждого домена?