Слот репликации и диск источника
Вопрос
Коннектор Debezium к PostgreSQL остановился на выходных из-за ошибки. В понедельник на боевой базе заканчивается диск. Почему?
Попробуйте сами
Выберите вариант, и откроется разбор.
Показать ответ и разбор
Коротко
Варианты ответа
- Debezium при остановке выгружает буфер необработанных изменений в файлы на диск базы
- PostgreSQL пишет в лог ошибки каждой неудачной попытки подключения коннектора
- Kafka Connect при недоступности брокера складывает события на сервер базы
- Слот логической репликации держит WAL, пока потребитель не подтвердит чтениеправильный ответ
Разбор
Слот гарантирует, что ни одно изменение не потеряется, поэтому PostgreSQL не удаляет WAL, который потребитель ещё не прочитал. Если потребитель стоит, WAL растёт до исчерпания диска. Нужно мониторить отставание слота (объём удерживаемого WAL) и иметь регламент: поднять коннектор или удалить слот с последующей повторной инициализацией. В PostgreSQL 13+ есть max_slot_wal_keep_size, ограничивающий удерживаемый объём ценой инвалидации слота. Остальные варианты не соответствуют реальному поведению.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Ещё по теме «CDC и инкрементальная загрузка»
- Удаления в аналитике
- Событие Debezium
- Transactional outbox
- Инкремент по водяному знаку
- Применить события Debezium к состоянию
- Поле op в событии Debezium
- Удаления при инкременте по updated_at
- Спроектируйте репликацию данных сервисов в хранилище через CDC