Спасибо за тёплые слова! Рад, что статья пригодилась в реальном проекте. Попробую ответит на оба вопроса CDC на slave вместо master — да, можно, но есть нюансы Для PostgreSQL это называется "logical replication from standby" и поддерживается с версии 16. До этого — только физическая реплика могла быть источником для другой физической реплики, но не для logical decoding. Что нужно:
PostgreSQL 16+ на реплике hot_standby_feedback = on (чтобы master не удалял нужные WAL-сегменты) wal_level = logical на master (т.к. standby наследует WAL от него)
В проде это хорошо: CDC-нагрузка уходит на реплику, master занимается только OLTP. Но добавляется лаг так как изменения сначала идут на master, потом на реплику, потом в Debezium. По второму: Деградация при чтении WAL всех таблиц Само чтение WAL — относительно дешёвая операция. PostgreSQL пишет WAL в любом случае (для crash recovery), а Debezium просто читает эти файлы через replication protocol. Где реальная нагрузка:
На уровне logical объём WAL растёт и на 3 репликах с сотнями таблиц это может быть + 20-40% к размеру WAL СЛот репликации держит WAL — если Debezium отстанет или упадёт, PostgreSQL не удалит старые сегменты. Диск может переполниться. И самое главное первичный снапшот при первом запуске когда Debezium делает SELECT * FROM table для каждой таблицы.
Я бы лучше начал с публикации нужных таблиц. Так легче контролировать что реплицируется и гибко управлять этим. На работе у нас вообще недопустимо реплицировать все, там бизнес говорит что им нужно, а что исключать
Рабочее решение. У меня была похожая идея, потом реализовал с сохранением в excel, но тут хотелось именно PostgreSQL → Debezium → Kafka — чтобы разобраться в стеке, который использую на работе
Согласен, для чистого учёта расходов — проще. Но цель цикла статей — построить CDC-пайплайн с нуля и разобраться как он работает. Скриншоты дают разнообразные события: INSERT при парсинге, UPDATE при верификации, DELETE при удалении мусора. Выписка дала бы только INSERT'ы
Что предлагаете использовать? Интересно было бы узнать
На чем писали? На Java? Закрытый проект или есть где посмотреть?
Спасибо за тёплые слова! Рад, что статья пригодилась в реальном проекте.
Попробую ответит на оба вопроса
CDC на slave вместо master — да, можно, но есть нюансы
Для PostgreSQL это называется "logical replication from standby" и поддерживается с версии 16.
До этого — только физическая реплика могла быть источником для другой физической реплики, но не для logical decoding.
Что нужно:
PostgreSQL 16+ на реплике
hot_standby_feedback = on (чтобы master не удалял нужные WAL-сегменты)
wal_level = logical на master (т.к. standby наследует WAL от него)
В проде это хорошо: CDC-нагрузка уходит на реплику, master занимается только OLTP.
Но добавляется лаг так как изменения сначала идут на master, потом на реплику, потом в Debezium.
По второму: Деградация при чтении WAL всех таблиц
Само чтение WAL — относительно дешёвая операция. PostgreSQL пишет WAL в любом случае (для crash recovery),
а Debezium просто читает эти файлы через replication protocol.
Где реальная нагрузка:
На уровне logical объём WAL растёт и на 3 репликах с сотнями таблиц это может быть + 20-40% к размеру WAL
СЛот репликации держит WAL — если Debezium отстанет или упадёт, PostgreSQL не удалит старые сегменты.
Диск может переполниться.
И самое главное первичный снапшот при первом запуске когда Debezium делает SELECT * FROM table для каждой таблицы.
Я бы лучше начал с публикации нужных таблиц. Так легче контролировать что реплицируется и гибко управлять этим. На работе у нас вообще недопустимо реплицировать все,
там бизнес говорит что им нужно, а что исключать
Рабочее решение. У меня была похожая идея, потом реализовал с сохранением в excel, но тут хотелось именно PostgreSQL → Debezium → Kafka — чтобы разобраться в стеке, который использую на работе
Согласен, для чистого учёта расходов — проще. Но цель цикла статей — построить CDC-пайплайн с нуля и разобраться как он работает. Скриншоты дают разнообразные события: INSERT при парсинге, UPDATE при верификации, DELETE при удалении мусора. Выписка дала бы только INSERT'ы
Есть опыт перехода скажем с одного уровня на другой, буквально месяц назад, но до такого мне ещё далеко. Спасибо за статью