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

SYSDBA: /* Вопросы */

2009-09-20T18:23:23Z

‎Вопросы

SYSDBA: /* Таблицы ЦБД */

2009-09-20T17:30:42Z

‎Таблицы ЦБД

SYSDBA: /* Таблицы ЦБД */

2009-09-20T16:07:36Z

‎Таблицы ЦБД

SYSDBA: /* Таблицы ЦБД */

2009-09-13T15:30:35Z

‎Таблицы ЦБД

SYSDBA: /* Таблицы ЦБД */

2009-09-11T19:14:51Z

‎Таблицы ЦБД

SYSDBA: /* Таблицы ЦБД */

2009-09-11T15:59:01Z

‎Таблицы ЦБД

SYSDBA: /* Домены */

2009-09-11T14:57:28Z

‎Домены

SYSDBA: /* Таблицы УБД */

2009-09-11T14:43:14Z

‎Таблицы УБД

SYSDBA: /* Концептуальная схема */

2009-09-11T14:39:35Z

‎Концептуальная схема

SYSDBA в 12:30, 11 сентября 2009

2009-09-11T12:30:05Z

@@ Строка 206: / Строка 206: @@
 # Как будут распространятся изменения через ЦБД до всех УБД, входящих в домен?
 # Как осуществляется нумерация изменений в рамках каждого домена?
 = Примечания =

@@ Строка 132: / Строка 132: @@
    CREATE TABLE rp2_domain_base (
      basekey    dintkey,
-     CONSTRAINT rp2_pk_domain_base PRIMARY KEY (basekey, domainkey)
+     CONSTRAINT rp2_pk_domain_base PRIMARY KEY (domainkey, basekey),
+   )
@@ Строка 143: / Строка 151: @@
      id         dintkey,
      domainkey  dintkey,
      classname  dname,
      subtype    VARCHAR(60),
      tablename  dtablename,
-     condition  dtext80,
+     condition  dtext254,
-−
+    CONSTRAINT rp2_pk_domain_class PRIMARY KEY (id),
+   )

@@ Строка 101: / Строка 101: @@
      name            dname UNIQUE,
      connection_data dtext254,
-−
-     PRIMARY KEY rp2_pk_base_id (id)
+     CONSTRAINT rp2_pk_base_id PRIMARY KEY (id)
+   )
@@ Строка 110: / Строка 110: @@
      id              dintkey,
      lock_rec        dinteger_notnull DEFAULT 1 UNIQUE,
-−
-     PRIMARY KEY rp2_pk_main_base_id (ID),
+     CONSTRAINT rp2_pk_main_base_id PRIMARY KEY (ID),
-     FOREIGN KEY rp2_fk_main_base_id (ID)
+     CONSTRAINT rp2_fk_main_base_id FOREIGN KEY (ID)
        REFERENCES rp2_base (id)
        ON DELETE CASCADE
@@ Строка 126: / Строка 126: @@
      generator_name dname UNIQUE,
-     PRIMARY KEY rp2_pk_domain_id (ID)
+     CONSTRAINT rp2_pk_domain_id PRIMARY KEY  (ID)
+   )
@@ Строка 135: / Строка 135: @@
      domainkey  dintkey,
-     PRIMARY KEY rp2_pk_domain_base (basekey, domainkey)
+     CONSTRAINT rp2_pk_domain_base PRIMARY KEY (basekey, domainkey)
+   )

@@ Строка 108: / Строка 108: @@
    CREATE TABLE rp2_main_base (
-     id     dintkey,
+     id              dintkey,
      PRIMARY KEY rp2_pk_main_base_id (ID),
@@ Строка 114: / Строка 115: @@
        REFERENCES rp2_base (id)
        ON DELETE CASCADE
-       ON UPDATE CASCADE
+       ON UPDATE CASCADE,
+   )

@@ Строка 98: / Строка 98: @@
    CREATE TABLE rp2_base (
-     id      dintkey,
+     id              dintkey,
-     name    dname UNIQUE,
+     name            dname UNIQUE,
      PRIMARY KEY rp2_pk_base_id (id)
+   )
-Идентификатор ЦБД:
+Идентификатор ЦБД, таблица хранит максимум одну запись:
    CREATE TABLE rp2_main_base (

@@ Строка 17: / Строка 17: @@
 http://gsbelarus.com/gs/images/gs/2009/repl_2.png
-Принадлежность объекта домену может устанавливаться только на основании его класса (вертикальное разбиение) или класса и принадлежности некоторому множеству (горизонтальное разбиение). Пример вертикального разбиения -- все объекты класса "Компания". Пример горизонтального -- все объекты класса "Компания", входящие в папку "Общие клиенты" справочника контактов.
+Принадлежность объекта домену может устанавливаться только на основании его класса (вертикальное разбиение) или класса и принадлежности некоторому множеству (горизонтальное разбиение). Пример вертикального разбиения &mdash; все объекты класса "Компания". Пример горизонтального &mdash; все объекты класса "Компания", входящие в папку "Общие клиенты" справочника контактов.
 В один момент времени изменение объектов в рамках одного домена возможно только на одной из баз, которая называется '''Активной базой данных домена''' (АБД). Активная база данных в начальный момент времени задается схемой репликации и называется '''Главной базой данных домена''' (ГБД). Статус активности передается по запросу от одной базы данных к другой. ГБД передает статус активности на ограниченный промежуток времени T<sub>a</sub>, по истечении которого ГБД снова становится активной, даже если она не посылала соответствующего запроса.

@@ Строка 60: / Строка 60: @@
      obj_class
      obj_subtype
      obj_state
      logged
+   )
@@ Строка 70: / Строка 74: @@
      obj_class
      obj_subtype
      obj_state_arch
      logged
+   )
@@ Строка 78: / Строка 86: @@
      expiration
+   )
    CREATE TABLE rp2_rbase (

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

@@ Строка 6: / Строка 6: @@
 Совокупность всех УБД и ЦБД, включенных в схему репликации, называется '''Распределенной базой данных''' (РБД).
 Циркуляция изменений в рамках распределенной базы данных происходит внутри т.н. '''доменов'''. Домен может состоять только из ЦБД, или ЦБД и одной или нескольких УБД. В РБД одновременно может существовать неограниченное количество доменов.
@@ Строка 17: / Строка 19: @@
 Принадлежность объекта домену может устанавливаться только на основании его класса (вертикальное разбиение) или класса и принадлежности некоторому множеству (горизонтальное разбиение). Пример вертикального разбиения -- все объекты класса "Компания". Пример горизонтального -- все объекты класса "Компания", входящие в папку "Общие клиенты" справочника контактов.
-В один момент времени изменение объектов возможно только на одной из баз, которая называется '''Активной базой данных''' (АБД). Активная база данных в начальный момент времени задается схемой репликации и называется '''Главной базой данных''' (ГБД). Статус активности передается по запросу от одной базы данных к другой. ГБД передает статус активности на ограниченный промежуток времени,
+В один момент времени изменение объектов в рамках одного домена возможно только на одной из баз, которая называется '''Активной базой данных домена''' (АБД). Активная база данных в начальный момент времени задается схемой репликации и называется '''Главной базой данных домена''' (ГБД). Статус активности передается по запросу от одной базы данных к другой. ГБД передает статус активности на ограниченный промежуток времени T<sub>a</sub>, по истечении которого ГБД снова становится активной, даже если она не посылала соответствующего запроса.
 по истечении которого ГБД снова становится активной, даже если она не посылала соответствующего запроса.
-В рамках домена, в один момент времени, редактирование или удаление объекта возможно только на одной базе данных. Такая база данных называется '''активной базой данных''' (АБД). Активная база данных в начальный момент времени задается схемой репликации и называется '''главной базой данных''' (ГБД). Статус активности передается по запросу от одной базы данных к другой. ГБД передает статус активности на ограниченный промежуток времени &mdash; T<sub>a</sub>, по истечении которого ГБД снова становится активной, даже если она не посылала соответствующего запроса. После передачи статуса активности БД становится неактивной. '''Неактивная база даных''' (НБД) функционирует в режиме только для чтения.
+После передачи статуса активности БД становится неактивной. '''Неактивная база даных''' (НБД) функционирует в режиме только для чтения.
 Мы будем использовать термин '''база данных''' (БД) в тех случаях, когда для нас не имеет значение является ли указанная база ЦБД или УБД в схеме репликации, имеет ли она статус активной или нет.
 Порядок выполнения действий над объектами на исходной базе должен строго сохраняться при переносе. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.
 = Реализация =