Очереди, потоки, события
Change data capture: запусти CDC и переживи застрявший slot
Читать про slot, заполняющий диск — не то же, что видеть, как это происходит, и остановить это. Подними реальный CDC, держи downstream-вью свежим из него, затем сломай consumer намеренно и докажи, что твои алерты и safety cap ловят это прежде, чем primary уйдёт в read-only.
Преврати ментальную модель юнита в воспроизводимый CDC-пайплайн плюс инцидент-дрилл: захватывай каждое изменение через Debezium, построй идемпотентный consumer, мониторь slot lag и продемонстрируй, что застрявший consumer сдерживается твоим cap, а не роняет Postgres.
Подними log-based CDC из таблицы Postgres orders в downstream-consumer, поддерживающий производную вью, затем прогони инцидент-дрилл застрявшего slot и докажи, что твой мониторинг + cap max_slot_wal_keep_size защищают primary — с доказательством на каждом шаге.
- Демо до/после: строка, вставленная, обновлённая и удалённая на primary, появляется корректно в downstream-вью в секундах, включая полную строку до удаления.
- Повторная доставка того же события дважды оставляет downstream-вью идентичной — доказывая, что consumer идемпотентен, а не просто удачлив.
- Панель мониторинга или лог, показывающий рост байтов удерживаемого WAL во время стопа и срабатывание алерта до давления на диск — измеренное, а не предположенное.
- Доказательство, что max_slot_wal_keep_size инвалидировал застрявший slot до disk-full, плюс краткий разбор, как ты восстановился (re-snapshot) и почему cap стоил цены re-snapshot.
- Добавь on-call runbook: шаги triage по панели slot-lag, как отличить отстающий consumer от долгой транзакции (pg_stat_activity), решение drop-vs-wait и чек-лист восстановления.
- Пропусти изменения через outbox-таблицу вместо прямого захвата доменной таблицы и покажи, что downstream-контракт событий остаётся стабильным при изменении схемы таблицы orders.
- Продемонстрируй порядок по ключу vs отсутствие глобального порядка: захвати две связанные таблицы и покажи cross-table consumer, который НЕ предполагает порядок коммитов между ними.
- Смени источник на MySQL (binlog) и сравни incremental snapshot vs блокирующий snapshot на большой таблице, записав окно заморозки записей для каждого.
Это дисциплина, которую ты будешь гонять в каждом реальном развёртывании CDC: захватывай через slot, бутстрапь через snapshot-then-stream, делай consumer идемпотентным, потому что доставка at-least-once, выставляй правильный REPLICA IDENTITY для delete и — самое важное — относись к slot как к заряженному ружью, мониторя его lag и ограничивая через max_slot_wal_keep_size. Загнать slot в стоп на игрушечной системе и увидеть, как твой cap спасает primary, превращает звонок в 3 ночи в мышечную память.