Фильтрация событий доступа для чтения в Debezium

Мы используем Debezium + PostgreSQL.

Обратите внимание, что мы получаем 4 типа событий для создания, чтения, обновления и удаления - c, r, u и d.

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

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

Как отфильтровать эти события в самом postgreSQL?

Я получил подсказку от одного из участников, чтобы использовать snapshot.mode. Я предполагаю, что нужно что-то сделать, когда Debezium создает снимок. Я не могу понять, как это сделать.


postgresql debezium
person user3911119    schedule 08.09.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Вероятно, ваша база данных существует уже некоторое время и содержит данные и изменения, которые были удалены из журналов логического декодирования. Если вы затем начнете использовать коннектор Debezium PostgreSQL для начала сбора изменений в Kafka, возникает вопрос, что должен видеть потребитель событий в Kafka.

Один из сценариев состоит в том, что потребитель должен иметь возможность видеть события для всех строк в базе данных, даже тех, которые существовали до запуска CDC. Например, это позволяет потребителю полностью воспроизводить / реплицировать все существующие данные и синхронизировать эти данные с течением времени. Для этого запуск коннектора Debezium PostgreSQL может начинаться с создания моментального снимка содержимого базы данных до того, как он начнет фиксировать изменения. Это выполняется атомарно, так что даже если для запуска процесса моментального снимка требуется время, соединитель все равно будет видеть все события, произошедшие с момента запуска процесса моментального снимка. Эти события представлены как события «чтения», поскольку в действительности соединитель просто считывает существующие строки. Однако они идентичны событиям «вставки», поэтому любое приложение может обрабатывать операции чтения и вставки одинаково.

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

Коннектор Debezium PostgreSQL будет работать в любом случае, поэтому вам следует использовать подход, который работает для того, как вы потребляете события.

person Randall Hauch    schedule 08.09.2017