Практикум по сбоям и контрактам
Восстановление состояния и границы доставки
Курс для инженеров, которые разбирают последствия сбоя: откуда база начинает повтор журнала, при каких условиях узел получает голос на выборах лидера и когда доставка «не более одного раза» вообще допустима.
Что вы сможете сделать
- Отделять позицию REDO контрольной точки от записи контрольной точки и фиксации транзакции.
- Фильтровать голоса и восстанавливать состояние узла перед выбором лидера Raft.
- Принимать контракт доставки только при явной допустимости потери и запрете повторной выдачи.
Модуль 1. Контрольная точка и начало REDO
При восстановлении важно отделять служебную позицию REDO от самой записи контрольной точки и от фиксации транзакции.
Запись последней контрольной точки содержит служебную позицию REDO; после сбоя восстановление использует указанное ею известное начало, а запись контрольной точки остаётся отдельным объектом.
Фиксация транзакции не требует отдельной контрольной точки: надёжно сохранённый WAL допускает отложенную запись страниц данных.
Выбор позиции REDO и вопрос о сохранности фиксации связаны восстановлением, но описывают разные факты контрольной точки и WAL.
Модуль 2. Голоса, состояние и свежесть журнала
Безопасный выбор лидера требует считать подходящие голоса в одном сроке, вернуть устойчивое состояние после перезапуска и сравнить журналы по правилам Raft.
Кандидат становится лидером после большинства голосов в новом сроке, а один сервер не голосует более одного раза за срок.
После перезапуска сохранённые currentTerm и votedFor возвращают ограничение одного голоса до обработки следующего выборного RPC.
Свежесть журнала определяется сначала сроком последней записи, а при равенстве сроков — индексом или длиной журнала.
Подсчёт большинства, восстановление состояния и сравнение журнала отвечают на разные вопросы одного выборного протокола.
Модуль 3. Когда подходит доставка не более одного раза
Контракт доставки выбирают по цене потери и повтора в заявленной области действия, сохраняя порядок фиксации позиции и обработки отдельным условием.
Доставка не более одного раза допускает потерю, но не повторную выдачу одного сообщения в заявленной области действия.
При фиксации позиции до обработки сбой между этими действиями может оставить сообщение необработанным и потерянным.
Пригодность контракта проверяют по допустимости потери и запрету повторной выдачи, а не по обещанию успешной обработки ровно один раз.
Проверьте инженерное мышление
Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.
Следующий шаг
Сформулируйте задачу и уточните требования к своей системе.
Подготовить состав проектаОткроется черновик вопроса. Отправьте его, когда будете готовы.
Источники курса
Ссылки приведены один раз для всего курса, чтобы не мешать чтению каждого тезиса.
- Официальная документация
PostgreSQL 18 Documentation: Write-Ahead Logging
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 28.3
Описывает порядок устойчивой записи WAL до изменённых страниц, восстановление страниц из журнала после сбоя и фиксацию транзакций без обязательного сброса всех изменённых страниц.
Открыть первоисточник - Официальная документация
PostgreSQL 18 Documentation: 28.5 WAL Configuration
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 28.5
Отдельная страница PostgreSQL 18, раздел 28.5: описывает сброс изменённых страниц, запись контрольной точки и позиции REDO, а также компромисс частоты контрольных точек между нагрузкой ввода-вывода и объёмом восстановления.
Открыть первоисточник - Первичная публикация
In Search of an Understandable Consensus Algorithm (Extended Version)
Stanford University / USENIX · Ongaro and Ousterhout, USENIX ATC 2014 extended paper
Первичное описание Raft: leader election, replicated log, commit majority и safety.
Открыть первоисточник - Официальная документация
Apache Kafka 4.0 Design
Apache Software Foundation · Apache Kafka 4.0 documentation
Определяет log ordering, producer idempotence, delivery semantics и scope exactly-once processing.
Открыть первоисточник