Распределённые данные · проверено по источникам

Двухфазная фиксация (2PC)

Двухфазная фиксация — протокол общего решения нескольких участников транзакции. Сначала участники сохраняют подготовленное состояние, затем координатор сообщает окончательную фиксацию или откат.

Также ищут: Two-Phase Commit · 2PC · двухфазная фиксация · distributed atomic commit

Практический смысл

Почему это важно

Подготовка участника не доказывает, что заказ окончательно зафиксирован у всех. Если координатор недоступен, нужно восстановить достоверное решение, пока подготовленные транзакции могут удерживать ресурсы.

Доказательная часть

Что подтверждено

  1. 2PC отделяет готовность участников от окончательного решения о фиксации или откате. Распределённая атомарность требует согласованного решения корректного менеджера транзакций, а не только успешного PREPARE у одного участника.

    Граница применимости: Классическая модель распределённой фиксации и механизм подготовленных транзакций PostgreSQL 18.

  2. PostgreSQL предназначает PREPARE TRANSACTION для внешнего менеджера транзакций. Менеджер должен доводить подготовленные транзакции до окончательного решения и восстанавливать эту работу после сбоя.

    Граница применимости: PostgreSQL 18; подготовленная транзакция не является удобной заменой обычной долгой транзакции приложения.

  3. После PREPARE TRANSACTION состояние сохраняется независимо от исходного сеанса и может пережить сбой базы. Другой сеанс позже завершает его командой COMMIT PREPARED или ROLLBACK PREPARED по идентификатору.

    Граница применимости: Подготовленные транзакции PostgreSQL 18 при исправном устойчивом хранении; действуют права на завершение транзакции.

  4. Подготовленная транзакция продолжает удерживать свои блокировки и мешать очистке старых версий VACUUM. Долгое забытое состояние поэтому может блокировать работу и обслуживание базы даже без живого исходного сеанса.

    Граница применимости: Эксплуатационные последствия подготовленных транзакций PostgreSQL 18.

  5. Успешный PREPARE заканчивает текущую транзакцию сеанса, но ещё не фиксирует её результат окончательно. Подготовленную работу нельзя продолжить обычными SQL-операциями как прежнюю открытую транзакцию; её нужно завершить отдельным решением.

    Граница применимости: PostgreSQL 18, состояние после PREPARE TRANSACTION до COMMIT PREPARED или ROLLBACK PREPARED.

  6. Недоступность координатора или большой возраст подготовленной транзакции не доказывает общего решения об откате. Произвольное завершение участника без восстановления решения может разойтись с уже принятым исходом у других участников.

    Граница применимости: Вывод из двухфазной фиксации и независимого prepared-состояния PostgreSQL 18; тайм-аут — повод для расследования, а не свидетельство безопасного отката.

  7. PostgreSQL не позволяет подготовить транзакцию, затронувшую временные таблицы, создавшую курсор WITH HOLD или выполнившую LISTEN, UNLISTEN либо NOTIFY. Поддержку PREPARE нужно проверять для фактического состава работы участника.

    Граница применимости: Ограничения PREPARE TRANSACTION PostgreSQL 18; не полный перечень требований менеджера транзакций.

Граница терминов

Не путать

Фиксация транзакции

Обычный COMMIT завершает локальную транзакцию. PREPARE TRANSACTION сохраняет готовность участника, а окончательное завершение откладывает до решения распределённого менеджера.

Атомарность транзакции

Атомарность — требование общего результата в заданной границе. 2PC — способ координировать его между участниками ценой подготовленного состояния и зависимости от восстановления решения.

Перед спецификацией

Что проверить

  1. Перечислите участников и назовите ответственный менеджер транзакций.
  2. Проверьте, что каждый участник поддерживает подготовку своего фактического набора операций.
  3. Отделите подтверждение PREPARE от окончательного решения о заказе.
  4. Сохраните идентификаторы участников и доступный после сбоя журнал решения координатора.
  5. Наблюдайте число и возраст подготовленных транзакций, блокировки и влияние на VACUUM.
  6. Испытайте сбой координатора до и после принятия окончательного решения.
  7. Завершайте забытое состояние по установленному общему решению, а не по одному тайм-ауту.
Открытые основания

Первоисточники

  • Первичная публикация

    The Transaction Model — Turing Award Lecture

    Microsoft Research / ACM · Jim Gray, FCRC 1999 lecture slides

    Первичный обзор transaction model, ACID, concurrency anomalies, logs и two-phase commit.

    Открыть первоисточник
  • Официальная документация

    PostgreSQL 18 Documentation: PREPARE TRANSACTION

    PostgreSQL Global Development Group · PostgreSQL 18 SQL command reference

    Описывает prepared transaction, external transaction manager и operational risk forgotten prepared state.

    Открыть первоисточник
Сообщить об ошибке

Опишите проблему — постараемся исправить как можно скорее.

Спасибо!

Получили ваше сообщение.
Подтвердите действие