Двунаправленная репликация#

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

Пререквизиты#

  • созданы технические пользователи и прописаны в конфигурацию (данные для подключения к БД);

  • сетевые доступы консоль-воркер, воркер-БД, воркер-Kafka открыты;

  • в модуле применения передано имя узла внутри секции соединения;

  • в модуле захвата задан параметр фильтрации внутри секции соединения.

Процесс#

  • консоль управления отправляет POST /process ко всем модулям;

  • консоль управления отправляет POST /start на воркер (содержит рабочую конфигурацию).

Модуль захвата:

  1. В зависимости от конфигурации подключается к топику Kafka или БД.

  2. Через соответствующий коннектор подключается к установленной базе данных и устанавливает JDBC-соединение.

  3. Подписывается на поток изменений WAL (позицию хранит сервер БД и Kafka).

  4. Сообщает модулю управления о готовности и начинает в цикле опрашивать поток репликации.

  5. Получает сообщения от потока репликации в формате pgoutput.

  6. При получении данных выполняется разбор бинарных данных, полученных из потока репликации, далее они сериализуется в MsgPack при отправке в Kafka.

  7. Прочитав данные, выполняет функцию предварительной преобразования (если настроена).

  8. Выполняет фильтрацию данных (если включено немедленное подтверждение транзакций, то прием отфильтрованных данных подтверждается вызовом функции flush_lsn().

  9. Присваивает транзакции идентификатор GradelyID в момент отправки в Kafka (при выполнении команды COMMIT, если маппинг не отфильтровал векторы изменений из этого коммита).

  10. В зависимости от конфигурации записывает данные в топик Kafka (GradelyID записывает в keys) или в БД.

  11. При установленном режиме полусинхронной репликации после успешной записи отправляет ответ в слот репликации об обработанном номере записи (lsn).

  12. Цикл чтения повторяется до получения запроса на остановку модуля. Вызов POST /stop воркера от консоли управления.

Модуль применения:

  1. Через соответствующий коннектор подключается к установленной базе данных и устанавливает JDBC-соединение.

  2. На основании переданного имени узла соединения выполняется ряд SQL-функций для установления источника транзакций

  3. На основании метаданных (предварительный запрос к БД приемника при старте модуля применения) формируются шаблоны SQL-запросов.

  4. Созданные шаблоны используются для генерации необходимых DML операций.

  5. Подключается к топику Kafka.

  6. Сообщает модулю управления о готовности и начинает в цикле опрос топика.

  7. В цикле читает данные и происходит формирование SQL (с учетом маппинга, фильтрации и преобразований).

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

  9. После успешного выполнения обработки набора транзакций записывает в топик обработки Kafka сообщение об успешной обработке.

  10. Есть возможность старта с произвольной точки (GraDeLyID).