Проект двунаправленной репликации: лучший способ для сценария и выполнения несопоставленной строки в исходной БД для нескольких абонентских БД, последовательно или одновременно?

Question

Спасибо за помощь или предложение.

Я пытаюсь создать собственную репликацию с несколькими хозяевами на Postgresql 10 в Windows для ситуации, когда невозможно использовать какой-либо из существующих сторонних инструментов для репликации с несколькими хозяевами PG, что может также включать другую платформу БД в группе подписчиков ( Sybase ADS). У меня есть следующая логика для создания двунаправленной репликации, частично вдохновленная логикой Bucardo, между 1 издателем и 2 подписчиками:

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

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

*** Я полагаю, что триггеры на подписчиках нужно будет приостановить, чтобы они не передавали свои принятые операторы своим подписчикам, т. Е. Если узел A и узел B оба подписываются на таблицу A друг друга, то выполняется обновление узла Таблица A А должна реплицироваться на таблицу A узла B без последующей репликации обратно на таблицу A в двунаправленном «пинг-понг-шторме».

3. Будет проведено окончательное сравнение таблиц, и транзакция будет закрыта. Повторно включите триггеры на подписчиках, если они были приостановлены / отключены при отправке транзакций из добавления шага 2.

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

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

Кто-нибудь видит, что этот план неисправен или может не работать?

Answer 1

Отказ от ответственности: я ничего не знаю о Postgresql, но сделал много пользовательских репликаций.

Основная проблема с двунаправленной репликацией - это проблемы слияния.

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

С какой задержкой вы можете справиться? Намного легче взять часть «уведомления» и просто иметь пятиминутное задание планировщика задач Windows, которое проверяет таблицы журналов и перемещает данные.

Другими словами, этот тип шаблона:

1. Изменение происходит в таблице. Триггер базы данных в этой таблице отмечает изменение и записывает PK таблицы в таблицу журнала изменений. Столбец ReplicationBatch в таблице журнала по умолчанию имеет значение NULL

2. Запланированная задача Windows проверяет все таблицы журнала изменений, чтобы найти все изменения, произошедшие с момента последнего запуска, и «резервирует» эти записи, устанавливая для их состояния репликации номер пакета репликации

т.е.. вы запускаете UPDATE LogTable Set ReplicationBatch=BatchNumber WHERE ReplicationState IS NULL

3. Все отмеченные записи реплицируются

вы запускаете SELECT * FROM LogTable WHERE ReplicationState=RepID, чтобы получить записи для обработки

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

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

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