![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Репликация таблицы БД с помощью очередей
Я тут, как обычно, подумываю, как бы заменить прямое обращение к БД из сервисов на хождение мессаг по очередям и посетила меня такая мысль: можно ли с помощью очереди, гарантирующей доставку "один раз или больше" реплицировать одну таблицу в БД, если у нее есть естественный ключ?
Мне что-то мерещится, что такая таблица является вариантом CRDT (если я воще правильно понимаю, что это такое) и можно гарантировать, что изменения с одной стороны, попавшие в очередь, дойдут до второй стороны и содержимое таблиц в конце-концов сойдется.
В случае гибели одной из БД и восстановления ее из резервной копии на какой-то момент времени, состояние рассинхронизируется и придется из второй БД принудительно передавать все данные, чтобы дозаполнить первую, или же хранить в БД полный лог изменений (заполняемый триггерами, например) и передавать изменения, начиная с момента логического времени, который видела умершая БД на момент своего резервного копирования.
Для случая нескольких таблиц со связями/FK уже так просто не получается - нужно чтобы таблицы, между которыми есть связи, реплицировались в правильном порядке - невозможно создать запись, в которой есть ссылки на другие, раньше их и удалить запись, на которую есть ссылки из других, до них невозможно.
Обычно я делаю распределенную транзакцию с двухфазной фиксацией с двумя БД и передаю данные лога транзакций и изменений между БД, пока оно работает как положено, за исключением того, что это прибивает гвоздями решение к протоколу Firebird, в котором эти распределенные транзакции предусмотрены и, например, убрать прямое обращение к БД и гонять данные по http(s) между сервисами не получается. Было бы интересно, опять же, рассмотреть вариант репликации данных между разными СУБД.
Мне что-то мерещится, что такая таблица является вариантом CRDT (если я воще правильно понимаю, что это такое) и можно гарантировать, что изменения с одной стороны, попавшие в очередь, дойдут до второй стороны и содержимое таблиц в конце-концов сойдется.
В случае гибели одной из БД и восстановления ее из резервной копии на какой-то момент времени, состояние рассинхронизируется и придется из второй БД принудительно передавать все данные, чтобы дозаполнить первую, или же хранить в БД полный лог изменений (заполняемый триггерами, например) и передавать изменения, начиная с момента логического времени, который видела умершая БД на момент своего резервного копирования.
Для случая нескольких таблиц со связями/FK уже так просто не получается - нужно чтобы таблицы, между которыми есть связи, реплицировались в правильном порядке - невозможно создать запись, в которой есть ссылки на другие, раньше их и удалить запись, на которую есть ссылки из других, до них невозможно.
Обычно я делаю распределенную транзакцию с двухфазной фиксацией с двумя БД и передаю данные лога транзакций и изменений между БД, пока оно работает как положено, за исключением того, что это прибивает гвоздями решение к протоколу Firebird, в котором эти распределенные транзакции предусмотрены и, например, убрать прямое обращение к БД и гонять данные по http(s) между сервисами не получается. Было бы интересно, опять же, рассмотреть вариант репликации данных между разными СУБД.
no subject
no subject
no subject
no subject
no subject
no subject
Не могу не обратить внимание на то, что нельзя забывать, что на слейве можно увидеть базу в таком состоянии, в каком ее нельзя увидеть на мастере (хотя к собственно очередям это отношения не имеет).
no subject
Для нескольких связанных таблиц можно даже не пытаться, бесполезно.
Кстати, а разве при групповом коммите ставится одинаковый логический таймстамп? Я думал, он там монотонно возрастающий.
no subject
no subject
В случае группового коммита ж это совсем не обязательно так!
Скажем, они выполнились последовательно, но записались одной транзакцией.
Чиста для технической экономии и оптимизации на этом.
no subject
Чиста для технической экономии и оптимизации на этом.
Если они пришли к коммиту вместе, то, стало быть, ни одна из них не ждала блокировок другой. Если так, он неважен порядок, в котором они выполняются - некоторая последовательность, полная параллельность или какая-то комбинация.
no subject
no subject
no subject
no subject
типа в каждой транзакции берём скрипт для выполнения и кладём его в таблицу аудита
а второе приложение эту таблицу читает и выполняет скрипты на другой базе
no subject
no subject
no subject
no subject
no subject
no subject
Это не моя фантазия. Это именно пример работающей системы построенной на базе очереди
no subject
no subject