Очереди, потоки, события
Change data capture: чтение конфига и запросов
Суть Прочитай конфиг Debezium, SQL по replication slot и строку лога slot-lag, предскажи поведение CDC и выбери фикс с наибольшим рычагом.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеПроблемы CDC диагностируются в конфиге коннектора и в собственных catalog-вью базы. Прочитай конфиг, SQL и строку мониторинга, затем выбери фикс, который senior-инженер сделает первым.
Цель
Отработай цикл, который ты гоняешь в каждом CDC-инциденте: прочитай настройку коннектора и состояние slot в каталоге, предскажи, где ломается удержание WAL или доставка, и возьмись за фикс с наибольшим рычагом.
Сниппет 1 — конфиг коннектора Debezium
{
"name": "orders-cdc",
"config": {
"connector.class": "io.debezium.connector.postgresql.PostgresConnector",
"plugin.name": "pgoutput",
"slot.name": "orders_slot",
"publication.name": "orders_pub",
"table.include.list": "public.orders",
"snapshot.mode": "initial",
"heartbeat.interval.ms": "0",
"tombstones.on.delete": "true"
}
} Викторина
Completed
Этот коннектор захватывает малонагруженную таблицу orders. Какая настройка — скрытый наполнитель диска и почему?
Heads-up snapshot.mode=initial снапшотит один раз на первом старте, потом стримит; он не пере-снапшотит на каждом рестарте. Это правильный дефолт для бутстрапа.
Heads-up Tombstones — крошечные null-записи, позволяющие compacted-топикам дропнуть удалённые ключи — они помогают compaction, а не заполняют диск источника. Риск диска здесь на Postgres, от slot, который не продвигается.
Heads-up pgoutput — встроенный плагин logical decoding, поставляемый с Postgres 10, и рекомендуемый выбор; он не меняет поведение удержания WAL.
Сниппет 2 — инспекция slot в каталоге
SELECT slot_name,
active,
pg_size_pretty(
pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
) AS retained_wal
FROM pg_replication_slots
WHERE slot_name = 'orders_slot';
-- slot_name | active | retained_wal
-- -------------+--------+--------------
-- orders_slot | t | 47 GB Викторина
Completed
Slot active = t, но удерживает 47 ГБ WAL. О чём это говорит и какой первый ход?
Heads-up active лишь означает, что consumer подключён; это ничего не говорит о том, продвигается ли restart_lsn. 47 ГБ удерживаемого WAL — риск переполнения диска независимо от флага active.
Heads-up Drop slot отбрасывает подтверждённую позицию коннектора и вынуждает полный re-snapshot. Сначала диагностируй, почему restart_lsn застрял — часто долгая транзакция — прежде чем трогать slot.
Heads-up pg_wal_lsn_diff между текущим WAL и restart_lsn — ровно стандартный способ измерить удерживаемый slot WAL. Это и есть запрос мониторинга, на который надо алертить.
Сниппет 3 — строка лога алерта slot-lag
WARN slot=orders_slot active=true retained_wal_bytes=50465865728
confirmed_flush_lsn=6F/A2000000 current_wal_lsn=7B/40000000
disk_used_pct=88 -> ALERT: slot lag exceeds 40GB threshold Викторина
Completed
Алерт срабатывает на 88% диска. Читая поля, какая верная интерпретация и порядок действий?
Heads-up Добавление диска выигрывает время, но не чинит застрявший slot — он снова заполнится. Разрыв LSN говорит, что slot не продвигается; нужно восстановить потребление или дать cap инвалидировать slot.
Heads-up confirmed_flush_lsn, отстающий от current_wal_lsn — норма: этот разрыв — просто непотреблённый WAL. Тревожит размер разрыва, а не его наличие. Перезапуск Postgres не делает ничего для застрявшего slot.
Heads-up active лишь означает, что consumer подключён. Подключённый consumer всё равно может сильно отставать или быть заблокирован открытой транзакцией; разрыв в 47 ГБ реален и алерт верен.
Сниппет 4 — подготовка таблицы к захвату полных delete
-- события delete сейчас несут только primary key в `before`
ALTER TABLE public.orders REPLICA IDENTITY FULL; Викторина
Completed
Ты запускаешь это, чтобы события DELETE несли полную строку до удаления. Какой побочный эффект senior-инженер отметит перед мержем?
Heads-up REPLICA IDENTITY FULL — изменение каталога, а не перезапись таблицы; он не перестраивает строки. Реальная цена постоянная: больше WAL на каждый update в дальнейшем.
Heads-up REPLICA IDENTITY влияет на то, что WAL логирует для изменений, а не на планирование запросов или использование индексов. Чтения не затронуты.
Heads-up Insert всегда логируют полную новую строку независимо от REPLICA IDENTITY. Настройка управляет лишь before-образом update и delete.
Итог
Каждый CDC-инцидент читается в конфиге и состоянии каталога: нулевой heartbeat голодит slot малонагруженной таблицы, пока WAL не заполнит диск; активный slot всё равно может удерживать десятки ГБ, если долгая транзакция заморозила restart_lsn, поэтому диагностируй pg_stat_activity, прежде чем что-то дропать; разрыв LSN в pg_replication_slots — то число, на которое ты алертишь, с max_slot_wal_keep_size как страховкой; а REPLICA IDENTITY FULL покупает полные образы delete ценой более жирных update. Сначала читай состояние slot, чини причину непродвижения и считай диск часами.