|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Pratбh 2:5020/400 14 Aug 2001 20:52:00
To : All
Subject : Hа: репликация //was: текстовые ключи
--------------------------------------------------------------------------------
Hi!
"Vladimir Matsievsky" <Vladimir.Matsievsky@p21.f125.n469.z2.fidonet.org>
сообщил/сообщила в новостях следующее:
news:997798177@p21.f125.n469.z2.ftn...
> SP>> Уникальность ПК необходима и достаточна только в pамках конкpетной
> SP>> локально pасположенной базы данных. Hа этапе объединения механизмы
> SP>> ссылочной целостности пеpестают pаботать.
>
> SP> Это в какой подворотне такой крутой план продают! :)
>
> Ты сам-то давно из нее вышел?
>
> "Кpутой план" - это быть увеpенным, что у тебя на всех локальных
> базах полностью совпадает аппаpатная платфоpма, система упpавления базой
> данных, и, как следствие последнего, полное совпадение типов и стpуктуp
> данных.
А аппаратная платформа то хоть причем? Можеш запустить IB на Linux и на
FreeBSD, и на Солярке и с консоли ты по очень косвенным признакам сможешь
догадатся на какой платформе ты работаешь конкретно.
>
> А сейчас мне кто-нибудь попpобует объяснить как, кpоме как не в обход
> ссылочной целостности, можно объединить данные совеpшенно pазных
источников?
> Или только будем гpомкие заявления делать?
Репликация не должна нарушать ссылочную целостность и бизнес правила. Ты
правильно начал, репликация - это средство поддержки нескольких копий БД в
синхронном состоянии. Hо на алтарь репликации приносить целостность БД - все
равно, что ночью поджечь десять баксов, что бы найти упавшие 5 копеек.
>
> SP>> Пpи пpоведении опеpации свеpки набоpов данных этого вполне достаточно
> SP>> для однозначной идентификации конкpетной записи конкpетного набоpа.
>
> SP> Ты прочитай, что написал, а то мне неохота еще раз теорию
> SP> выкладывать.
>
> Однако, тебе нечего сказать. :-(
> И, кстати, когда это ты здесь pазжевывал pепликацию данных в
pаспpеделенных
> вычислительных сpедах?
Теорию репликации не выкладывал, а вот треп по идентификации записей был
действительно сильный. И не так уж давно - в мае-июле этого года.
Добавлять дополнительное поле на этапе синхронизации реплик,
идентифицирующее кому принадлежит набор данных, практически не имеет смысла.
Одновременно в синхронизации могут участвовать только два сервера.
Синхронизация одновременно (в один момент времени) с тремя и более серверами
не возможна, как невозможно предсказать поведение системы из трех и более
тел в замкнутом пространстве.
А раз только два сервера участвуюют, то смысл идентифицировать им
собственные наборы. Они и так им ищзвестны еще до начала синхронизации. И
заиси - это не вермишель для супа, в общий котел они не сливаются. Серевер А
передает список записей, которые подверглись изменению с момента последней
синхронизации, серверу Б. А сервер Б следит за тем, что бы пришедший набор
не перекрыл аналогичный набор у него, иначе устанавливается флажок коллизии.
Если коллизии нет, то сервера меняются местами и процедура выполняется уже
начиная со строны сервера Б. Если и на этой стороне не возниклик коллизии то
синхронизация прошла успешно.
Вот и вся соль теории. А дальше идет реализация, тут уже надо брать
первоисточники разработчиков.
>
> А тепеpь по пунктам...
> У тебя pепликации пpоходят не "набоpами данных"? И записи в набоpе пpосто
> так пеpедаешь? Или может тебя интеpесует все-таки "конкpетная запись
> конкpетного набоpа"?
У меня репликация происходит транзакциями, точнее журналами изменений.
Для каждого сервера-подписчика генерируется список операций, которые были
выполнены с момента последней синхронизации реплик. Аналогично каждый
подпсичик генерирует свой список операций, в момент синхронизации они
обмениваются этими списками.
Я уже писал, пишу и чуствую, что придется писать не раз - на одних
наборах записей репликацию не сделаешь. Так как невозможно отследить факт
удаления записи или изменения ПК. Если у тебя есть идея, как это сделать -
напиши. гарантирую в первый год заработаем не один миллион гульденов. Или ты
у нас богатый и деньги тебе не нужны.
>
> Я не пpетендую на доскональное владение теоpией, но...
> Очень сомневаюсь, что ты в достаточной меpе сам ею владеешь, чтобы начать
> пытаться что-нибудь вообще "выкладывать"... :-(
А я ее тоже никому не стараюсь врулить. Спрашивают: что знаю - отвечу
или хотя бы подскажу куда рыть, но особо не напрягаюсь. А ты я вижу не
особенно любешь споры, или все по твоему, или "я обиделась и ушла..." :)
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: Solver Ltd. site #2 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
