Репликация таблицы БД с помощью очередей

[metaclass]

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

Мне что-то мерещится, что такая таблица является вариантом CRDT (если я воще правильно понимаю, что это такое) и можно гарантировать, что изменения с одной стороны, попавшие в очередь, дойдут до второй стороны и содержимое таблиц в конце-концов сойдется.

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

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

Обычно я делаю распределенную транзакцию с двухфазной фиксацией с двумя БД и передаю данные лога транзакций и изменений между БД, пока оно работает как положено, за исключением того, что это прибивает гвоздями решение к протоколу Firebird, в котором эти распределенные транзакции предусмотрены и, например, убрать прямое обращение к БД и гонять данные по http(s) между сервисами не получается. Было бы интересно, опять же, рассмотреть вариант репликации данных между разными СУБД.

Comments

[vromanov.livejournal.com]

Можно. Так иногда и делается. Например в TimesTen. Там пишется при изменении данных лог изменений. И он просто проигрывается на втором узле

[plumqqz.livejournal.com]

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

Распределенные транзакции можно проводить с помощью аппликейшен серверов или в той или иной степени самодельно - начиная от атомикоса какого и заканчивая собственным кодом (там не так все сложно).

Я бы на себя взял наглость посоветовать подумать об отказе от репликации вообще в силу ее концептуальной мутности.

[vromanov.livejournal.com]

"сообщения в очереди не упорядочены" - это тогда не очередь

[plumqqz.livejournal.com]

Я так понимаю, у вас какие-то свои определения. Ну, ради бога, пусть не очередь.

[vromanov.livejournal.com]

Акроним FIFO вам ничего не говорит? Отличия очереди от стека не проходили? Кстати, какой вуз вы закончили и как давно?

[plumqqz.livejournal.com]

Вы, кажется, вообще не понимаете о чем речь.

[vromanov.livejournal.com]

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

[plumqqz.livejournal.com]

Потому что из очереди (да и из топика) у вас консумеры могут получать сообщения одновременно, и как там обработчики при обработке отшедулятся - бог весть (это еще не учитывая случаи redelivery), для репликации же требуется получать правильно упорядоченные изменения, причем не по времени собственно изменения, а по времени коммита транзакции, которая сделала эти изменения, что тоже может быть нетривиальным занятием, и не надо забывать случай группового коммита - когда несколько транзакций коммитятся пачкой и идут с одним таймстампом. Ну и, разумеется, нельзя не заметить, что на слейве необходимо повторять все транзакции в чистом виде, с begin/commit, чтобы в случае чего можно было восстановиться.
Не могу не обратить внимание на то, что нельзя забывать, что на слейве можно увидеть базу в таком состоянии, в каком ее нельзя увидеть на мастере (хотя к собственно очередям это отношения не имеет).

[metaclass.livejournal.com]

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

Кстати, а разве при групповом коммите ставится одинаковый логический таймстамп? Я думал, он там монотонно возрастающий.

[plumqqz.livejournal.com]

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

[nivanych.livejournal.com]

> если транзакции подошли к коммиту вместе, то, стало быть, они не пересеклись

В случае группового коммита ж это совсем не обязательно так!
Скажем, они выполнились последовательно, но записались одной транзакцией.
Чиста для технической экономии и оптимизации на этом.

[plumqqz.livejournal.com]

Скажем, они выполнились последовательно, но записались одной транзакцией.
Чиста для технической экономии и оптимизации на этом.
Если они пришли к коммиту вместе, то, стало быть, ни одна из них не ждала блокировок другой. Если так, он неважен порядок, в котором они выполняются - некоторая последовательность, полная параллельность или какая-то комбинация.

[nivanych.livejournal.com]

Да, я несколько стормозил, спасибо.

[slonopotamus.livejournal.com]

ВНЕЗАПНО, порядок важен для читающих транзакций, которые выполнялись одновременно с этими пишущими.

[plumqqz.livejournal.com]

Ссылаться на себя как-то не тово, но все-таки перечитайте тред с начала.

[berezovsky.livejournal.com]

а в приложении нельзя доступ к базе сериализовать?

типа в каждой транзакции берём скрипт для выполнения и кладём его в таблицу аудита

а второе приложение эту таблицу читает и выполняет скрипты на другой базе

[plumqqz.livejournal.com]

Да ради бога, только осортируйте в порядке коммитов.

[berezovsky.livejournal.com]

так я про это и спрашиваю, если в приложении каждую операцию записи в бд обернуть в lock/WaitForSingleObject/wtf на глобальный хэндл, разве коммиты не пойдут в хронологическом порядке

[plumqqz.livejournal.com]

Ну сами себе прострелите ногу - будете выполнять все строго последовательно. В принципе работать должно, конечно, но зачем?

[metaclass.livejournal.com]

Пойдут, но работать будет невозможно

[vromanov.livejournal.com]

Это работает и для связных таблиц. Естественно транзакции на мастере должны быть такими же транзакциями на слейве.

[vromanov.livejournal.com]

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

[plumqqz.livejournal.com]

Ну молодцы, молодцы.

[juan-gandhi.livejournal.com]

Я бы хотел напомнить, что последовательность и упорядочивание - две разные вещи.

[vissarion.livejournal.com]

Концепция event sourcing write-ahead log
по сути во многих бд так и происходит
в оракле по-крайней мере именно так
первым делом в журнал пишется действие еще до начала операции, журнал же реплицируется на вторую бд
(проигрыванием журнала можно однозначно восстановить состояние бд на любой момент)
а потом уже идёт собственно само действие в бд

[juan-gandhi.livejournal.com]

А я что-то вообще на коленке с нуля раз навалял, ну очереди мессаг (вроде WAL), с трассировкой, кто что видел, идет оно по сетке, как законфигурируешь раутинг.

Собственно, речь шла об hbase, так что идеология уже присутствовала.

[vromanov.livejournal.com]

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

[metaclass.livejournal.com]

Да, сейчас такое у меня работает.

[hshhhhh.livejournal.com]

У вас немного закат солнца вручную :)

[nealar.livejournal.com]

У них огнептица.

[madeveloper.livejournal.com]

CRDT подразумевает наличие что-то типа SCN в Oracle (System Change Number).
"Монотонно увеличивающегося состояния" в понимании CRDT.
Если ввести в таблицу поле аналогичное SCN, то можно легко выгребать записи изменившиеся с момента последней репликации, и так же легко отсеивать ранее учтенные обновления.
В свое время делал на подобном принципе систему синхронизации данных по накопительным картам в сети заправок.

[plumqqz.livejournal.com]

У вас будут проблемы с удалением. Правда, и это решаемо, но получается чуток сложнее.