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х случаях: БД менят свои записи,
БД получает изменения в чужих записях в процессе репликации.
Для определения порядка изменений системный таймер не используется.

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