Я использую встроенный Debezium, и мне кажется, что он отлично работает в единой среде разработки приложений. Однако у меня есть опасения по поводу того, что это будет в среде с несколькими узлами, где несколько экземпляров приложения будут пытаться открывать соединения с одной и той же БД для мониторинга журнала. Нужна ли реализация пула соединений? Я не могу найти информацию об этом в документации.
Управление подключением к встроенной базе данных Debezium / объединение в пул
comment
Могу я спросить, почему вы используете встроенный режим? Потоковая передача в Kafka (через обычный стиль развертывания Kafka Connect) позволяет использовать несколько потребителей событий изменений (из тем Kafka) с помощью одного считывателя журнала изменений. Кроме того, если ваши узлы приложения были частью одной группы потребителей, только один из них мог бы обрабатывать каждое событие. Было бы интересно узнать больше о вашем конкретном сценарии использования, чтобы дать более весомый совет.
- person Gunnar schedule 24.11.2019
comment
Kafka не вариант для нас (решение компании). Мы находимся в положении, когда нам нужно решение pub / sub, где мы хотим синхронизировать таблицу БД с базой данных в памяти, опять же решение компании. У нас был какой-то старый экземпляр кролика, который, как мне сказали, мы больше не поддерживаем, так что здесь довольно мало. Встроенный Debezium, кажется, соответствует нашим потребностям, и мы можем реализовать его, не нарушая архитектуру. Меня беспокоит только то, что несколько приложений подключаются обратно для чтения Таблицы журналов БД могут быть проблемой. У нас в производстве 12 экземпляров, которые будут указывать на одну и ту же БД. Спасибо
- person dean0bambin0 schedule 25.11.2019
Ответы (1)
Хотя я не являюсь экспертом в Debezium, я все же управляю портфелем IBM Data Replication, поэтому данный ответ имеет это в виду.
Определения:
Канал изменений данных = вставки, обновления, удаления, сделанные в одну или несколько таблиц, захваченных в журнале восстановления / транзакции / отмены
Как правило, если у вас есть несколько потребителей канала событий измененных данных, подходящим вариантом дизайна было бы поместить этот канал в очередь один раз, а затем иметь несколько считывателей в этой очереди, избегая необходимости иметь несколько считывателей журнала.
После этого очередь может быть прочитана несколькими потребителями. Примерами очередей являются «промежуточные таблицы аудита», т. Е. Таблицы, содержащие поток изменений. Вам нужно будет периодически обрабатывать таблицы аудита, чтобы они не разрастались до больших размеров.
Другой популярный выбор - постановка на Кафку. Кафка ориентирован на многих читателей с небольшим количеством писателей.
Некоторые зрелые продукты (например, портфель IBM Data Replication) имеют функции, точно разработанные для удовлетворения сценария использования многих потребителей исходной ленты изменений, то есть так называемого «очистки кеша» или «единственного очистителя». Таким образом, инструменты репликации могут отправлять исходный канал изменений многим целевым объектам, включая базы данных, Hadoop и Kafka, при этом в исходной базе данных читается только один журнал.
Ваше здоровье!
person
Glenn Steffler
schedule
21.11.2019
