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

SYSDBA: /* Изменение объекта и регистрация изменения на одной транзакции */

2009-09-20T14:26:01Z

‎Изменение объекта и регистрация изменения на одной транзакции

SYSDBA: /* Состояние базы данных */

2009-09-01T12:50:21Z

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

SYSDBA: /* Регистрация несущественных изменений */

2009-08-31T07:49:24Z

‎Регистрация несущественных изменений

SYSDBA: /* Регистрация несущественных изменений */

2009-08-29T13:21:38Z

‎Регистрация несущественных изменений

SYSDBA: /* Регистрация несущественных изменений */

2009-08-28T15:15:26Z

‎Регистрация несущественных изменений

SYSDBA: /* Очередность сохранения объектов и формирование потока */

2009-08-28T15:08:18Z

‎Очередность сохранения объектов и формирование потока

SYSDBA в 18:12, 24 августа 2009

2009-08-24T18:12:27Z

SYSDBA: /* Структура сообщения */

2009-08-24T13:02:33Z

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

SYSDBA: /* База B */

2009-08-24T13:00:56Z

‎База B

SYSDBA: /* База B */

2009-08-24T13:00:37Z

‎База B

← Предыдущая		Версия 14:26, 20 сентября 2009
Строка 208:		Строка 208:

	Во избежание рассинхронизации реального состояния объекта с информацией в логе, изменение объекта и регистрация в логе его нового состояния должны происходить на одной транзакции.		Во избежание рассинхронизации реального состояния объекта с информацией в логе, изменение объекта и регистрация в логе его нового состояния должны происходить на одной транзакции.
		+
		+	= Ссылки по теме =
		+
		+	[http://delicious.com/goldensoftware/replication Ссылки по теме "Репликация баз данных".]

	[[Category:Постановка]]		[[Category:Постановка]]

@@ Строка 82: / Строка 82: @@
 == Состояние базы данных ==
-Мы будем называть целое число S состоянием базы данных. Если S = М, значит все изменения переданы на ЦБД. Если S < M, -- необходимо осуществить передачу. Ситуация, когда S > M означает серьезный сбой в данных репликации, нарушение логической целостности.
+Мы будем называть целое число S состоянием базы данных. Если S = М, значит все изменения переданы (для УБД) или все изменения приняты и успешно записаны в базу (для ЦБД). Если S < M, -- необходимо осуществить передачу. Ситуация, когда S > M означает серьезный сбой в данных репликации, нарушение логической целостности.
 В начальный момент времени:
@@ Строка 88: / Строка 88: @@
    S = M = 0
-Базы данных А и B находятся в идентичном состоянии, если M<sub>a</sub> = S<sub>b</sub>.
+Базы данных А и B находятся в идентичном состоянии, если M<sub>a</sub> = S<sub>a</sub> = S<sub>b</sub>.
 Состояние УБД увеличивается на единицу каждый раз, когда подтверждается передача очередного объекта. S<sub>a</sub> равно максимальному номеру записи в логе в состоянии C.

← Предыдущая		Версия 07:49, 31 августа 2009
Строка 204:		Строка 204:

	Триггеры регистрации в логе изменений не должны реагировать на изменение только значений технических полей (например, LB и RB для интервальных деревьев).		Триггеры регистрации в логе изменений не должны реагировать на изменение только значений технических полей (например, LB и RB для интервальных деревьев).
		+
		+	=== Изменение объекта и регистрация изменения на одной транзакции ===
		+
		+	Во избежание рассинхронизации реального состояния объекта с информацией в логе, изменение объекта и регистрация в логе его нового состояния должны происходить на одной транзакции.

	[[Category:Постановка]]		[[Category:Постановка]]

@@ Строка 203: / Строка 203: @@
 === Регистрация несущественных изменений ===
-Триггеры регистрации в логе изменений не должны реагировать на изменение объекта, когда меняются только значения технических полей (например, LB и RB для интервальных деревьев).
+Триггеры регистрации в логе изменений не должны реагировать на изменение только значений технических полей (например, LB и RB для интервальных деревьев).
 [[Category:Постановка]]

@@ Строка 203: / Строка 203: @@
 === Регистрация несущественных изменений ===
-Триггеры регистрации в логе изменений объектов не должны реагировать на изменение только технических полей LB и RB для интервальных деревьев.
+Триггеры регистрации в логе изменений не должны реагировать на изменение объекта, когда меняются только значения технических полей (например, LB и RB для интервальных деревьев).
 [[Category:Постановка]]

← Предыдущая		Версия 15:08, 28 августа 2009
Строка 200:		Строка 200:

	Механизм сохранения в поток платформы Гедымин рекурсивно обходит все ссылки, от которых зависит сохраняемый объект. Возможна ситуация, когда в логе будут находиться последовательно изменения объектов A, B, C. Объект А зависит от С. Тогда, при сохранении в поток объекта A, через ссылки, сохранится и объект C. Это приведет к нарушению строгой очередности передачи объектов в соответствии с порядком изменений в логе. В таком случае, в момент формирования потока при сохранении объекта А, необходимо остановить процесс и информировать системного администратора.		Механизм сохранения в поток платформы Гедымин рекурсивно обходит все ссылки, от которых зависит сохраняемый объект. Возможна ситуация, когда в логе будут находиться последовательно изменения объектов A, B, C. Объект А зависит от С. Тогда, при сохранении в поток объекта A, через ссылки, сохранится и объект C. Это приведет к нарушению строгой очередности передачи объектов в соответствии с порядком изменений в логе. В таком случае, в момент формирования потока при сохранении объекта А, необходимо остановить процесс и информировать системного администратора.
		+
		+	=== Регистрация несущественных изменений ===
		+
		+	Триггеры регистрации в логе изменений объектов не должны реагировать на изменение только технических полей LB и RB для интервальных деревьев.

	[[Category:Постановка]]		[[Category:Постановка]]

← Предыдущая		Версия 18:12, 24 августа 2009
Строка 1:		Строка 1:
	Рассмотрим вариант однонаправленной репликации между двумя базами A и B. Все изменения осуществляются на базе A. База B работает в режиме только для чтения. В дальнейшем, мы будем использовать термины "Удаленная база данных (УБД)" для базы А и "Центральная база данных (ЦБД)" для B.		Рассмотрим вариант однонаправленной репликации между двумя базами A и B. Все изменения осуществляются на базе A. База B работает в режиме только для чтения. В дальнейшем, мы будем использовать термины "Удаленная база данных (УБД)" для базы А и "Центральная база данных (ЦБД)" для B.
		+
		+	http://gsbelarus.com/gs/images/gs/2009/repl_ab_1.png

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

@@ Строка 189: / Строка 189: @@
 *** Диапазон номеров изменений в логе.
 ** '''"Запрос на передачу объекта"'''
-*** Число S<sub>b</sub> + 1.
+*** Диапазон от S<sub>b</sub> + 1 до наименьшего номера изменения, переданного в сообщении "Передача объекта".
 Контрольная сумма используется для проверки корректности всех данных сообщения, включая и заголовок.

@@ Строка 163: / Строка 163: @@
 ### Если номер изменения первого сообщения в очереди меньше S<sub>b</sub> + 1, то игнорируем такое сообщение. Удаляем его и продолжаем обрабатывать очередь. В журнал помещаем запись о несанкционированной повторной передаче уже принятого объекта.
 ### Если номер изменения первого сообщения в очереди больше S<sub>b</sub> + 1, то прекращаем обработку очереди. Текущее сообщение не удаляем. На УБД отсылаем сообщение '''"Запрос на передачу объекта"''', где указываем диапазон изменений, которые нас интересуют: с S<sub>b</sub> до номера изменения первого сообщения в очереди, не включая границы.
-## По окончании обработки очереди (не важно, полной или частичной), отсылаем на УБД сообщение '''"Подтверждение передачи объектов"''' с указанием номеров изменений, успешно записаных в ЦБД.
+## По окончании обработки очереди (не важно, полной или частичной), отсылаем на УБД сообщение '''"Подтверждение передачи объектов"''' с указанием номеров изменений, успешно записанных в ЦБД.
 ## При возникновении конфликта записи объекта в ЦБД останавливаем обработку очереди. В лог ЦБД заносим пометку номера изменения и ставим ему статус F. Информируем системного администратор о серьезном сбое репликации.