repl2.narod.ru
- незамысловатый алгоритм репликации моего изобретения.
Хотелось бы услышать конструктивную критику от специалистов.
Надеюсь, что кому-то эта статья окажеться полезной (хотя бы ссылки на литературу:)

Distort1) Ваша схема не отрытие. Я лично подобную схему реализовал еще полтора года назад (правда потом понял, что она пригодна лишь для статичных проектов - см.п.3)
2) "Запись изменяется и удаляется только в той ЛБД, в которой была создана (схема ведущий-ведомый)." - представьте себе систему документооборота, построенную по этому принципу :) представили?........ а я нет
3) Схема сама по себе сложна и любое ее расширение (добавление нового объекта в БД) требует внушительных по времени доработок.

1) К сожалению, я Вашу схему не видел.
Если бы Вы дали ссылку, то можно было бы сравнить.
2) Если схему трудно применить к документообороту, то её не надо для этого применять
или надо доработать. Считаю, что доработать можно.
3) Я бы не сказал, что схема так уж сложна по сравнению с теми, что я видел.
Модифицирование БД часто непростая задача, а с репликацией, естественно, сложнее.
Если это необходимо, то добавление нового объекта можно автоматизировать.

Distort
Повторюсь - схема подобная. Однако, я не публикую свои решения, поэтому ссылку дать не могу.

Наверное, изобретателям репликаторов стоит объединить свои усилия:)

Distort
Это был всего лишь пример. Вы, видимо, не уловили суть проблемы.

Кажеться мы друг-друга не поняли.
Я пошёл на ограничение возможностей РБД для упрощения алгоритма.
Поэтому выбрал схему "ведущий-ведомый".
Думаю что алгоритм можно относительно легко модифицировать,
и разрешить изменения во всех ЛБД
но тогда прийдётся менять способ разрешения конфликтов обновления.
Distort
Так у Вас не Репликатор, а целая Платформа получится :)

Почему "Платформа"? Просто не прототип а конечный продукт.

DistortРекомендую обратить Ваше внимание на то, что чаще всего не все данные РБД1 требуются РБД2.
В своей схеме я реализовал такую фишку (схема типа "отправитель-подписчик" - все это оформляется на репликаторе, который и распределяет всю нагрузку). До этого передавался слишком большой объем ненужной информации.
Ценное замечание.
У меня БД-клиент вызывает на БД-сервере процедуры типа MASTER_GEN .
(надо было наверное сразу дать ссылку на документацию Doc )
Думаю, что если надо ограничить набор данных то можно добавить в процедуру дополнительный параметр - кот будет задавать условие в клаузе WHERE

guest_20040621По прочтении остался один вопрос: почему это названо репликацией?
Может, Вы понимаете этот термин иначе.
Дайте определение.

tygra guest_20040621По прочтении остался один вопрос: почему это названо репликацией?
А я еще добавлю: зачем пирдуман странный и ужасный механизм поколений, их двухэтапность и т.д. Я к тому же так и не понял, каким образом данные все-же попадают с одной БД в другую и зачем там запрашивать счетчик поколений. Кроме кучи странных методов процесс попадания данных в базу непонятен.

Собственно про выводы в статье:

Зачем это все? Зачем пункты 6.1 и 6.3, если и без них все можно сделать хорошо?

И что за таинственная программа Replication.exe?

У нас есть свой обмен данными, только он намного проще и понятнее. И без пунктов 6.1 и 6.3.

-- Tygra's --
Мои фотогалереи тут
Механизм поколений может и странный но не ужасный.
Придуман он для регистрации изменений (позволяет обойтись без системного таймера, от которого одни неприятности).
Двухэтапность - для того что бы изменения не оказались скрыты от клиента (это может произойти в особо замороченных случаях. у меня в статье есть пример )
Изменения попадают из одной БД в другую с помощью таинственной программы Replication.exe, которая вызывает кучу странных методов :)
Запрашивать счётчик поколений у БД-сервера надо для того, что бы сравнить его с сохранённым на БД-клиенте(сравнить со счётчиком, кот. был на сервере во время предыдущей репликации) и понять, что на сервере изменилось (если равны - ничего не изменилось).
tygra
У нас есть свой обмен данными, только он намного проще и понятнее. И без пунктов 6.1 и 6.3.

Я ни к кому не навязываюсь. Если для задачи подходят стандартные средства, то естественно их и надо применять. Если у Вас есть свой обмен данными, интересно на него посмотреть.

tygraЯ к тому же так и не понял, каким образом данные все-же попадают с одной БД в другую и зачем там запрашивать счетчик поколений. Кроме кучи странных методов процесс попадания данных в базу непонятен.

Возможно я изложил свои идеи недостаточно ясно. Постараюсь учесть все замечания.
По замыслу статья, документация по БД и исходники должны друг друга дополнять:)
(исходники: http://repl2.narod.ru/Replicator_1_beta_src_only.zip ; документация http://repl2.narod.ru/Doc_Replicator_1_beta.zip

tygraНе-не-не, я не хочу рассматривать никакие исходники.

Вы словами можете написать?
Например: таинственный Replication.exe идет на одну БД, там делает селект того, что изменилось, делает селект конкретной таблицы и делает инсерт по этому селекту в другую БД.
Типа такого хватит. Или словами описать, что делают методы.

Иначе непонятно, каким именно путем данные ходят - с помощью этой ехе, через DTS, из БД в БД напрямую или как-то еще.

И зачем получать новый счетчик все же - вы храните чтоли всю историю изменений? А зачем?

Ну и про механизм поколений - хоть двухэтапный, хоть одноэтапный - я вообще не понял. Что такое поколение, зачем оно....

==========

По поводу своего механизма: если кратко, в нужных местах отписываются события в отдельную таблицу событий обмена. По этой таблице идет ехе, который получает по событию данные и отгоняет в БД-получатель. Работает все через ХП. Никаких поколений, timestamp или чего еще такого. Все тупо и просто, заодно гибко. В таблице событий лежит ссылка на первичный ключ - обычно это ID - по которому потом забираются данные.

-- Tygra's --
Мои фотогалереи тут
Могу и словами.
---
Поколения служит для определения порядка изменений.
Это просто счётчик (generator).
Произвели кучу изменений, присвоили им поколение напр. 1
Произвели ещё кучу, присвоили поколение 2.
и т.д.
(каждой записи в таблице данных XXX соответствует запись в таблице LOG_XXX, куда поколение и записывается).
Потом такими кучами изменения и передаются.
---
История конечно не хранится. Храниться одно число - счётчик поколений.
Напр. приняли кучу изменений с поколением 2, запомнили 2.
В след. раз запросили у сервера счётчик, а у него он равен 4.
Знач надо принять поколения 3 и 4.
---
Данные ходят след. образом: replicator.exe коннектится к клиенту и серверу и перегоняет изменения.
---
Изменения replicator.exe перегоняет так: надо напр. принять изменения в таблице MASTER,
вызывается процедура MASTER_GEN на сервере, входной параметр - значение счётчика поколений.
Процедура смотрит в LOG_MASTER находит записи, у кот поколение равно входному параметру,
возвращает набор записей и инфу, что с ними делать (вставить, удалить, изменить).
Этот набор записей временно сохраняется в таблице MASTER_INPUT а потом изменения применяются к таблице MASTER на клиенте (выполняются вставки изменения удаления).
==================
Наверное, Ваш метод похож на описанный в http://home.sinn.ru/~mapnn/articles.html . В там кстати описывается проблема скрытия изменений (из-за чего я и сделал двухэтапную установку поколений). Наск. я понял у вас одна таблица для всех изменений базы в кот заносится ID записи и таблица в кот. произошло изменение. А как Вы решили проблему с уникальными идентификаторами?
А у меня напр. БД можно соединять как угодно: каждую с каждой и т.д.,
причём они могут передавать и принимать данные одновременно (лишь бы БД не принимала одну и ту же запись одновременно от разных серверов) :)

C ID ясно.
У меня по большому счёту так же сделано, просто диапазоны другие:)
У Вас, наск. я понял, на каждый рекордсет есть хранимая процедура на передающей БД и на принимающей.
Интересная идея с типами обмена. Судя по описанию, очень гибкая.
Я так понимаю, что получается двухуровневая иерархия:
тип обмена-рекордсеты; данные сразу разбиваются на логические группы.
Возникают вопросы:
Что будет, если принимающая БД обратиться к передающей второй раз?
она получит те же изменения + новые или только новые?
Если только новые, то как это сделано?
(предполагаю, что лог очищается, но тогда у передающей БД должна быть только одна принимающая)

tygraВообще после того, как обмен успешно прошел, то в логе эта запись уничтожается. Если обмен в несколько БД должен быть, для каждой БД создается своя запись.

Такой подход, наверное, решает проблему скрытия изменений, зато требует больше памяти.

tygra
Изменений собственно то и не передается как таковых - передаются те данные, которые есть на момент запроса от обмена - все данные, какие найдутся. Т.е. независимо от того, менялись данные или нет, все данные по конкретному типу обмена приносятся и меняются - до того, как обмен сработает, можно 10 раз поменять данные, но запись об обмене останется одна. Но можно ведь сделать отдельный тип обмена, который будет срабатывать только по конкретным изменениям, и который будет приносить только те данные, которые в этом случае нужны. Например, при создании чего-то, по этому "чего-то" нужно принести естественно все данные. А при смене статуса "чего-то" можно просто сделать обмен с типом "Изменение статуса" и отписывать только его - а он принесет только данные о статусе, т.к. вообще все данные в этот момент не нужны.

Получается, это не только передача данных, а и передача событий тоже.

Почему-то вспоминается MVC или Документ-Представление.
Похоже это действительно не репликация БД, а репликация объектов,
которые просто хранятся в БД.
А почему возникла необходимость сделать именно так?
Просто Ваш подход сильно отличается от тех, что я встречал.

И что использовалось для реализации (СУБД и т.д.)?

tygraMS SQL, Delphi
Наск. я знаю, в MS SQL есть стандартные средства репликации,
хотя с событиями наверное ни однин стандартный репликатор не работает:)


Случайно наткнулся на целую россыпь тем по репликации:
/topic/357703&hl=%f0%e5%ef%eb%e8%ea%e0%f6%e8%ff
http://www.rsdn.ru/Forum/Message.aspx?mid=2100448&only=1
http://www.rsdn.ru/Forum/Message.aspx?mid=1269536
http://www.rsdn.ru/File/84/primary_keys_and_replication.zip

Dogen авторзначение logical clock увеличивается после каждого события (в данном случае событие ‑ изменение), таким образом, можно восстановить очерёдность изменений в одной ЛБД, но нельзя восстановить очерёдность изменений в РБД, т.к. нельзя сравнивать значения logical clock в разных ЛБД
Кому, интересно, нужна такая "репликация?"

===============================================================================<BR> Отвечать без смысла на это письмо. <BR>Сообщение направлено вам роботом доски объявлений.

Приведенная цитата - это только пояснения отличия моего метода от описанного в источнике (см. статью ), поэтому риторические вопросы считаю необоснованными:)

А почему Вы считаете, что для репликации необходимо знать порядок изменений в РБД?
(системный таймер этого напр. не гарантирует)

В моём случае на каждой локальной БД как бы свой отсчёт времени.
Поэтому сравнивать "время" разных БД нельзя. Но это и не нужно.
Для того, что бы определить, какие изменения произошли достаточно знать очерёдность событий в локальной БД (т.е. клиенту достаточно знать очерёдность изменений сервера, причём очерёдность групп а не единичных изменений).

Dogen
Ух ты как интересно. Раз системный таймер не гарантирует , то проблемы такой ни у кого нет?

Непонятный логический переход.

У меня такой проблемы нет.

Dogen
Вот Вы попробовали бы изобрести алгоритм, отслеживающий точную хронологию изменений записи в разных БД без использования системного таймера, вот это было бы дело.

Так что вопрос не риторический, риторические вопросы задавать мне недосуг.

У меня записи менются только в той БД, в которой созданы.
т.е. изменения в БД происходят в 2х случаях: БД менят свои записи,
БД получает изменения в чужих записях в процессе репликации.
Для определения порядка изменений системный таймер не используется.

Зачем Вам всё-таки точная хронология?

Dogen nomadeЗачем Вам всё-таки точная хронология?
Для разрешения update-конфликтов.

У Вас такой проблемы нет, зато у тех кто пользуется подобными системами, есть. И решают эту проблему отнюдь не красивыми способами - иногда и надо отредактировать запись в филиале компании, а не разрешают. Ждут центр.
В моей схеме репликации проблему тоже можно решить "некрасивым" способом:
разрешить изменения и заменить поле LOG_OWN_GEN "собственное поколение записи"
( см. пример таблицы данных )
на timestamp. Тогда для определения порядка изменений в БД будут по-прежнему использоваться поколения, а при разрешении конфликтов - timestamp.
Т.к. методов разрешения конфликтов много (timestamp, приоритет БД, разруливание вручную и т.п.), то я в прототипе эту проблему проигнорировал.
Можно напр. сделать как в Delphi: если мы изменили запись в филиале, отправляем в центр,
и выясняем, что в центре эту запись поменял кто-то другой, то запись возвращается обратно для ручного разруливания.

contr nomade Dogen nomadeЗачем Вам всё-таки точная хронология?
Для разрешения update-конфликтов.В моей схеме репликации проблему тоже можно решить "некрасивым" способом:
Уважаемый nomade, обратите внимание, что оперировать таблицами при построении перспективного (или неперспективного...) репликатора - не очень удачная идея по двум причинам:
1) Ваш продукт будет конкурировать со штатными решениями по репликации, присутствующими в арсенале любой СУБД. Причем конкурировать с заведомо проигрышной позиции, поскольку претендует на универсальность, в то время как решения от вендоров тесно интегрированы с СУБД.
2) Если Вы всерьез задумались о разрешении конфликтов встречных изменений, то обратите внимание на следующее: данные в БД обновляются транзакциями. Транзакция может затрагивать более одной таблицы и выполняться продолжительное время.

Пусть есть таблицы Т1, Т2 и их реплики R1, R2.
Пусть над T1, T2 проведена транзакция, поменявшая записи
T1Rec10 - в момент времени 10
T2Rec25 - в момент времени 20
В то же время над репликой было проведено похожее действо (встречное обновление):
R1Rec10 - в момент времени 12
R2Rec25 - в момент времени 18

К какому результату приведет Ваше "некрасивое" решение по разрешению конфликта на базе отдельных таблиц, поколений и timestamp? Гарантирует ли оно целостность (непротиворечивость) данных?

ИМХО если и строить что-то свое, то лучше на принципах, подобных изложенным tygra - с ориентацией на бизнес-смысл потоков данных, а не на их физическое хранение.

Ценные замечания.
2)Признаюсь, я про обновления на разных БД толком не думал.
А это, как оказалось, серьёзный недостаток.
На краткость транзакций надеяться не приходится, время и так не слишком надёжно.
Пока что вижу такое решение описанной Вами проблемы:
применить двухэтапную установку времени (как в поколениях) :).
Получится такая штука:
Пусть есть таблицы Т1, Т2 и их реплики R1, R2.
Пусть над T1, T2 проведена транзакция, поменявшая записи
T1Rec10 - момент времени: NULL
T2Rec25 - момент времени: NULL
Записи недоступны для репликации.
Перидически заупскается транзакция, кот. устанавливает поколения,
одновременно она устанавливает и время:
T1Rec10 - момент времени: 30
T2Rec25 - момент времени: 30
Записи доступны для репликации.
В то же время над репликой было проведено похожее действо (встречное обновление):
R1Rec10 - момент времени: NULL
R2Rec25 - момент времени: NULL
Потом установили время:
R1Rec10 - момент времени: 20
R2Rec25 - момент времени: 20
---
Целостность сохраняется (пока ИМХО. надо проверить:)
Время оценивается конечно грубовато.

1)Да я сознаю, что область применения самописных методик очень небольшая.
Но, судя по форумам, такая необходимость иногда всё-таки есть.
У меня пока не продукт а прототип, который ИМХО можно приспособить к конкретной ситуации.

contr
ИМХО если и строить что-то свое, то лучше на принципах, подобных изложенным tygra - с ориентацией на бизнес-смысл потоков данных, а не на их физическое хранение.

Мне сложно сказать.
Готовых репликаторов действительно много.
А описаний методик почему-то мало:) Может моя схема кому-то пригодится.

ShultzeЗря напали на человека
А по моему нормальный механизм репликации, сам применял подобный в паре проектов, идею придумал не я, взял отсюда:
Репликация AD
Если не касаться частностей, то это аналог приведенной реализации

Приятно слышать, что подходы, подобные моему, применяются на практике.
В статье, наск. я понял, речь идёт о репликации объектов.
Как этот подход можно применять к БД?

Dogen ShultzeЗря напали на человека
А по моему нормальный механизм репликации, сам применял подобный в паре проектов, идею придумал не я, взял отсюда:
Репликация AD
Если не касаться частностей, то это аналог приведенной реализации
А никто не спорит. Человек попросил заценить, а ему говорят, что мастер-слэйв неинтересно и в самом деле может быть реализовано встроенными средствами серверов (хотя я бы делал все сам, к примеру).
Обсуждение на форуме - неплохой способ для "стресс-тестирования" метода.
Кроме многочисленных достоинств моего метода обнаружились и некоторые недостатки:)
Несколько раз критиковалась схема мастер-слэйв. Похоже от неё таки прийдётся избавиться.
Вопрос к экспертам: достаточно ли позволить всем БД изменять чужие записи но запретить удаление? Или все БД должны иметь возможность и удалять чужие записи?

Dogen
В АД репликация сетевая, попарно между серверами, в режиме мастер-мастер. Ничего общего.
Сеть можно и у меня сделать: соединять БД можно как угодно и две БД могут одновременно реплицироваться друг с другом.
(правда, не мультимастер:( )

Dogen nomadeВопрос к экспертам: достаточно ли позволить всем БД изменять чужие записи но запретить удаление? Или все БД должны иметь возможность и удалять чужие записи?
Это к заказчикам вопрос, а не к экспертам. Если Вы занимаетесь общим случаем, то всё нужно.
С удалением и так проблем много:)
Тогда можно по-другому спросить: насколько часто втречается необходимось удалять чужие записи?
(хотя конечно если делать общий алгоритм, то надо или всё запретить или всё разрешить:)

DogenУ Вас какой-то подход не от жизни.

Удалять на определенном уровне абстракции надо разрешать всё, а запрещать - это уже уровень выше, т.е. уровень бизнес-логики.

При этом физического удаления записей не должно происходить.

Просто я не привязываюсь к конкретным примерам.

Валентин КДля централизованных систем линейная репликация серверов БД не годится.. и интересно, кто расскажет что это не так...

наск. я понял, для ценрализованных систем не годится репликация "каждый с каждым".
т.к. иерархическая система проще, то из репликации "каждый с каждым" всегда можно сделать репликацию "центр-филиалы".

Валентин К
Статью прочитал бегло, не понял зачет версионность.

Если имеется ввиду поле LOG_OWN_GEN "собственное поколение записи"
(см. пример таблицы данных) , то оно для разрешения кофликтов обновления.

Если вы про поколения, то они для того, что бы определить какие изменения произошли.
Клиенту достаточно хранить одно число - старое значение счётчика поколений сервера,
что бы понять, что на сервере изменилось.
Валентин К
Практическая модель централизованной репликации есть, что тоже не велосипед.

Я не спорю. Даже привёл список ссылок на другие статьи.

Валентин К
Зачем вообще версионность и зачем по ней определять что-то? это тупиковая мысль, рабочая, но иррациональная. Можете применять. Но реально лучше сделать проще, надежней и быстрее.

Обоснуйте своё высказывание.
Что конкретно Вы предлагаете взамен?

Валентин КУ меня есть, и ссылки на нее нету, потому что в инет не выкладывал.

Очень плохо.
Валентин К
Всяких статей читал. На практике смотрел. В основном - фигня.

Сильное утверждение:)
Валентин К
Считаю основным критерием работоспособноть модели на больших объемах данных, все остальное - нажитие гимороя. Кто считает иначет - слушаю ваши "за".

Для проверки работоспособности в разных ситуациях к статье прилагается прототип.

Валентин К
Не всегда. Вы работали с реальными системами учета, или только с демобазой из поставки Борланда?
Не работал. Зато участвовал в создании:)

Валентин К
Статья продуманная, теория вроде гладкая... вобщем риспект. Зерно правильного мышления есть.
Спасибо за риспект:)