Репликация FB + Delphi.... Варианты исполнения

Добрый!
Стоит задача реплицирования данных с одной БД в другую, расположенную на удаленном по сети ПК.
Причем, если быть точным реплика идет из нескольких БД в Одну, т.е. с нескольких ПК на СЕРВЕР.
Я подумал, сделать следующее - создаю ssl-туннель (сжатие данных + безопасность) между компами и пишу Replicator, который устанавлиется на сервере и по рассписанию соединяется с БД клиентов и выполняет
"remote"select и "local"insert + (необходимые преобразования если необходимо).
Как это делать - для меня понятно (как идентифицировать новые записи - тоже).
Однако возникает вопрос - логичен ли такой подход???
Почитал ссылки на ibase.ru по репликации там рассмотрено решение установки клиент-сервера реплиции. Т.е. сервак говорит "хочу" - клиент (локально) эти данные готовит и пересылает серверу в виде ZIP (DBF etc), сервер разбирает файл и делает insert. Но это существенно сложнее (по времени исполнения ))).
В моем варианте меня лишь напрягает операция удаленного соединения с БД. Критичен ли при этом возможный разрыв соединения на этапе выполнения удаленного запроса на выборку данных???

ИМХО, но если всё это хозяйство в локалке, то можно и с сервера запросом выбирать, но я бы ещё сделал что-то вроде контроля, например первый запрос на кол-во реплицируемых данных, потом формирование промежуточной таблицы (может даже и External Tables использовать), потом сравнение кол-ва реплицируемых данных и данных в промеж. таблице, при совпадении заливать в рабочую, если удачно, то говорить клиенту, что всё гуд (ну метить записи как удачно реплицированные или что там ещё...)
можно ещё следить за разрывом коннекта...

автор

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

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

Короче вывод такой: надо делать систему с учётом подобных коллизий. Практически это означает что ты должен иметь возможность сделать импорт в базу-приёмник, подтвердить все транзакции и только потом пометить в базе источнике что импорт закончен. В случае же сбоя твоя система должна уметь
без проблем повторно накатывать ранее загруженные изменения. Из этого следует что хорошо бы объединить команду INSERT и UPDATE в режим MERGE. Это можно сделать на FB2 с помощью EXECUTE BLOCK:

EXECUTE BLOCK (...) AS BEGIN UPDATE MY_TAB SET ... IF (ROW_COUNT = 0) INSERT INTO MY_TAB ... END

S@shka

Т.е. сервак говорит "хочу" - клиент (локально) эти данные готовит и пересылает серверу в виде ZIP (DBF etc), сервер разбирает файл и делает insert. Но это существенно сложнее (по времени исполнения ))).

А в чем сложности? На клиенте данные для репликации вытаскиваешь в ClientDataset, и вызываешь метод SaveToFile. Дальше пакуешь, переправляешь на сервер, а там ClientDataSet.LoadFromFile и инсерть себе...

Gold

Я не знакю как там двухфазный коммит устроен, но всё равно уверен что такая ситуация там возможна.

Кхм...

Я не знакю как там двухфазный коммит устроен, но всё равно уверен что такая ситуация там возможна.

не знаешь - прочитай. www.ibase.ru/devinfo/ibtrans.htm

при использовании 2PC бояться надо не этого, а другого. Вот цитата из пока неопубликованной статьи (если в некоторых местах сложно написано - извините, это черновой вариант):

...

Двухфазный commit

Казалось бы - в чем уязвимость этой вполне отработанной технологии? Давайте рассмотрим ее характеристики и варианты применения.

2PC стартует транзакцию над несколькими базами данных, и обладает определенной логикой применения изменений в случае сбоя на этапе подтверждения (commit) такой транзакции. Для того, чтобы во всех базах данных, участвующих в распределенной транзакции, данные были или применены или отменены, до commit или rollback в каждой базе данных такая транзакция помечается состоянием "in Limbo". Это означает, что до момента окончательной фиксации или отмены изменений ни в одной из таких базах данных версии, помеченные такой транзакцией, нельзя было бы удалить отдельно. То есть, это требование согласованности такой транзакции.

Значит, версии записей, помеченные "in Limbo", нельзя удалить, их нельзя обновить, и даже для backup есть специальный ключ -L, позволяющий игнорировать такие версии записей. Отсюда мы делаем вывод, что если при выполнении транзакции 2PC произошел сбой, то нормальная работа приложений может быть парализована до устранения "застрявших" версий записи путем commit/rollback двухфазной транзакции на всех базах данных, участвовавших в транзакции.

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

- базы данных, участвующие в транзакции 2PC, находятся на одном компьютере (сервере).
Здесь нет никаких проблем, т.к. либо сервер работает и доступ к обоим базам данных есть, либо сервер не работает целиком. То есть, время восстановления в случае работы сервера минимально - запускаем gfix в автоматическом режиме или в ручном режиме указываем что делать с такими транзакциями (вопрос повреждения одной из базы не рассматриваем, все это уже было описано выше).

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

- базы данных находятся на компьютерах, разделенных модемной связью. Например, между такими базами данных производится репликация путем использования транзакций 2PC.
Это худший из вариантов, потому что нарушение модемной связи может прозойти по массе причин и на непредсказуемо длительный срок. Если не предусмотрен другой способ доставки реплицируемых данных на тот или иной сервер, никакого другого выхода кроме как gbak -b -L (создать резервную копию с игнорированием версий in Limbo и восстановленить БД из резервной копии) нет.

Отсюда делаем вывод, что наихудшим вариантом является использование 2PC на модемной связи.

...

2 Лентяй:
А что кхм? Как не крути, а команды процессор выполняет можно сказать последовательно. Так что даже если представить двухфазный коммит двумя последовательными командами процессора, то всё равно будет промежуток в пару тиков когда одна команда выполнена, а другая нет. :-) Реально там конечно не тики, но маленькая вероятность есть всё равно. Во всяком случае я так думаю.

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

2 kdv: Я в обшем-то читал статью про 2PC, даже несколько раз, и в целом имею представление как оно работает. Но дело в том что я диплом писал на тему репликации и долго кумекал как же они так могли сделать чтобы гарантировалось подтверждение или откат транзакции в обоих базах. Если нарисовать временные диаграммы, то становиться очевидно что никак. Фактически двухфазный коммит даёт скорее больше проблем чем преимуществ. Теоретически безпроблемная репликация может быть только в случае безпроблемного повторного наката ранее внесённых изменений и правильным вабором последовательности действий.

Дадо переносить изменения, подтверждать их, и после этого подтверждать успешное перенесение данных в удалённой базе. И без всяких двухфазных комитов.

Gold

Дадо переносить изменения, подтверждать их, и после этого подтверждать успешное перенесение данных в удалённой базе. И без всяких двухфазных комитов.

это точно, да и проблем меньше, ИМХО конечно...
полностью поддерживаю

Если нарисовать временные диаграммы, то становиться очевидно что никак.

сие есть ахинея полная, потому что если нарисовать и правда диаграммы состояний, то все становится просто и понятно. Никакие "миллисекунды" никого не колышат, пусть даже и секунды, речь именно о гарантированном commit/rollback в обоих базах.
Механизм до того простой, и более того ОБЩЕПРИНЯТЫЙ, что мне наоборот, непонятно вот что -

долго кумекал как же они так могли сделать чтобы гарантировалось подтверждение или откат транзакции в обоих базах.

Есть еще трехфазный коммит, на сайте есть письмецо Харрисон с перечислением его состояний. Но трехфазного коммита в промышленных системах практически никто не видел, ибо достаточно двухфазного.