Очереди, потоки, события
Change data capture: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту CDC — риск replication slot, удержание WAL, стратегия snapshot, захват delete, семантика доставки и порядок.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь, эксплуатируя CDC в production — не определение для заучивания, а сбой, который надо разобрать прежде, чем он тебя разбудит.
Цель
Убедись, что связываешь механизм slot, удержание WAL, стратегию snapshot, захват delete и семантику доставки — тот синтез, к которому вёл урок.
Викторина
Completed
Воркер Kafka Connect коннектора Debezium ловит OOM и лежит шесть часов на нагруженной OLTP-машине. Какой главный риск для исходного Postgres и почему?
Heads-up События не теряются — slot держит WAL именно чтобы коннектор мог продолжить со своего LSN. Опасность обратная: удерживаемый WAL растёт, пока не переполнится диск.
Heads-up Logical slot по дизайну переживает отключения — в этой устойчивости весь смысл и именно поэтому он опасен. Postgres инвалидирует его только если задан max_slot_wal_keep_size и порог превышен.
Heads-up Postgres продолжает принимать записи — именно это растит WAL. Он останавливается, только когда диск реально полон.
Викторина
Completed
Твой CDC-коннектор выглядит полностью здоровым — потребляет, lag около нуля — но WAL на primary продолжает расти и диск заполняется. Самая вероятная причина?
Heads-up Re-snapshot читает существующие строки; сам по себе он не пинит WAL вверх. Замороженный restart_lsn из-за открытой транзакции — классическая причина роста при здоровом на вид коннекторе.
Heads-up Slot не увеличивает генерацию WAL — он лишь управляет тем, как долго сегменты удерживаются. Удержание растит диск, только когда что-то мешает confirmed-позиции продвигаться.
Heads-up Back-pressure от Kafka может застопорить consumer (это видно как lag), но не меняет то, как Postgres пишет WAL. Подсказка здесь — lag около нуля, что указывает на замороженный restart_lsn.
Викторина
Completed
Нужно забутстрапить CDC на многотерабайтной таблице MySQL под постоянными записями, и нельзя замораживать записи на часы. Какая стратегия snapshot подходит и в чём компромисс?
Heads-up Блокирующий snapshot (FLUSH TABLES WITH READ LOCK) — именно то, что замораживает записи на большой таблице на неприятное окно, чего бриф на многотерабайтной таблице запрещает.
Heads-up Лог содержит только недавние изменения, а не текущее состояние каждой существующей строки. Пропуск snapshot оставит downstream без всех строк, не менявшихся после старта.
Heads-up Временная метка — не позиция репликации; нельзя надёжно совместить логический дамп с точным offset binlog, поэтому рискуешь пропуском или нахлёстом на стыке. Incremental snapshot существует, чтобы чисто совместить snapshot и stream.
Викторина
Completed
Событие DELETE из Postgres приходит с before-образом, содержащим только primary key, а downstream нужна полная строка до удаления. Что происходит и какова цена фикса?
Heads-up Debezium эмитит ровно то, что содержит WAL для этой таблицы. Before-образ только из ключа из-за REPLICA IDENTITY, а не из-за лимита размера у коннектора.
Heads-up Vacuum освобождает мёртвые кортежи, но не управляет тем, что WAL логирует для DELETE. Образ до удаления задаётся REPLICA IDENTITY на уровне таблицы.
Heads-up Tombstone — это запись с null-значением после удаления, позволяющая compacted-топикам Kafka дропнуть ключ — данных строки в ней нет. Полный before-образ даёт REPLICA IDENTITY FULL.
Викторина
Completed
Команда говорит: «Debezium 2.x даёт exactly-once, так что consumer может пропустить дедуп». Где ломается это рассуждение?
Heads-up Гарантия заканчивается на Kafka. При resume с последнего подтверждённого LSN коннектор может пере-эмитить события, а падение consumer между чтением и commit переобработает их — дубликаты downstream всё ещё возможны.
Heads-up Debezium точно отслеживает offset через slot/LSN — так он и продолжает. Именно точный resume и может вызвать повтор событий после подтверждённой точки.
Heads-up Порядок между партициями — отдельная забота. Причина, по которой нужна идемпотентность — дублирующая доставка при resume, независимо от порядка.
Викторина
Completed
Consumer джойнит изменения из таблицы orders и таблицы payments и предполагает, что видит их в порядке коммитов. Почему при Debezium-to-Kafka это предположение небезопасно?
Heads-up Kafka гарантирует порядок внутри партиции. Проблема в том, что две таблицы/ключа попадают в разные партиции, где порядок между партициями не обещан.
Heads-up Глобального потока в порядке коммитов между партициями нет. Порядок только по ключу; джойн между таблицами не может полагаться на порядок коммитов.
Heads-up REPLICA IDENTITY управляет тем, что логирует delete, а не порядком. Порядок между таблицами — свойство партиционирования, не связанное с identity.
Итог
Сквозная линия юнита — одна цепочка следствий: безусловное обещание slot по WAL делает CDC возобновляемым и оно же переполняет диск, когда consumer застрял или долгая транзакция заморозила restart_lsn; бутстрап — это snapshot-then-stream, где incremental snapshot меняет простоту на старт без lock; захват полных delete стоит объёма WAL через REPLICA IDENTITY FULL; а поскольку resume — at-least-once с порядком только по ключу, consumers должны быть идемпотентными и не предполагать глобальный порядок коммитов.