15.3.8 XA Transactions — MySQL 8.4

15.3.8 XA-транзакции

Поддержка транзакций доступна для InnoDB движка хранения. Реализация XA в MySQL основана на документе X/Open CAE Обработка распределённых транзакций: Спецификация XA. Этот документ опубликован The Open Group и доступен по адресу http://www.opengroup.org/public/pubs/catalog/c193.htm. Ограничения текущей реализации XA описаны в разделе 15.3.8.3 «Ограничения XA-транзакций».

На стороне клиента нет специальных требований. XA-интерфейс к серверу MySQL состоит из SQL-выражений, начинающихся с ключевого слова XA. Программы клиентов MySQL должны уметь отправлять SQL-выражения и понимать семантику интерфейса XA-выражений. Им не нужно связываться с последней библиотекой клиента. Также работают более старые библиотеки клиентов.

Среди коннекторов MySQL, MySQL Connector/J 5.0.0 и выше поддерживает XA напрямую, с помощью интерфейса класса, который обрабатывает XA-SQL-выражения за вас.

XA поддерживает распределённые транзакции, то есть возможность разрешить участию в глобальной транзакции множеству отдельных транзакционных ресурсов. Транзакционные ресурсы часто являются СУБД, но могут быть и другими типами ресурсов.

Глобальная транзакция включает несколько действий, которые сами по себе являются транзакционными, но все они должны либо успешно завершиться как группа, либо все быть отменены как группа. По сути, это расширяет свойства ACID “наверх”, так что несколько транзакций ACID могут быть выполнены в комплексе как компоненты глобальной операции, которая также имеет свойства ACID. (Как и в случае с нераспределёнными транзакциями, SERIALIZABLE может быть предпочтительным, если ваши приложения чувствительны к явлениям чтения. REPEATABLE READ может быть недостаточным для распределённых транзакций.)

Некоторые примеры распределённых транзакций:

Приложение может выступать в качестве инструмента интеграции, объединяющего службу обмена сообщениями с СУБД. Приложение гарантирует, что транзакции, связанные с отправкой, получением и обработкой сообщений, которые также включают транзакционную базу данных, происходят в рамках глобальной транзакции. Можно представить это как “транзакционную электронную почту”.
Приложение выполняет действия, которые включают разные серверы баз данных, такие как сервер MySQL и сервер Oracle (или несколько серверов MySQL), где действия, которые включают несколько серверов, должны происходить в рамках глобальной транзакции, а не как отдельные транзакции, локальные для каждого сервера.
Банк хранит информацию об счетах в СУБД и осуществляет распределение и получение денег через автоматические банкоматы (АТМ). Необходимо гарантировать, что действия АТМ правильно отражены в счетах, но это невозможно сделать только с помощью СУБД. Управляющий глобальной транзакцией интегрирует ресурсы АТМ и базы данных, чтобы обеспечить общую согласованность финансовых транзакций.

Приложения, использующие глобальные транзакции, включают один или несколько менеджеров ресурсов и менеджера транзакций:

Менеджер ресурсов (RM) обеспечивает доступ к транзакционным ресурсам. Сервер базы данных — это один из видов менеджера ресурсов. Должно быть возможно либо подтвердить, либо откатить транзакции, управляемые RM.
Менеджер транзакций (TM) координирует транзакции, которые являются частью глобальной транзакции. Он взаимодействует с RM, которые обрабатывают каждую из этих транзакций. Отдельные транзакции в рамках глобальной транзакции являются “ветвями” глобальной транзакции. Глобальные транзакции и их ветви идентифицируются схемой именования, описанной позже.

Реализация XA в MySQL позволяет серверу MySQL действовать как менеджеру ресурсов, который обрабатывает XA-транзакции в рамках глобальной транзакции. Программа клиента, подключающаяся к серверу MySQL, выступает в роли менеджера транзакций.

Для выполнения глобальной транзакции необходимо знать, какие компоненты участвуют, и привести каждый компонент к состоянию, когда он может быть подтверждён или отменён. В зависимости от того, что каждый компонент сообщает о своей способности к успеху, все они должны либо подтвердить, либо отменить как атомную группу. То есть, либо все компоненты должны подтвердить, либо все компоненты должны отменить. Для управления глобальной транзакцией необходимо учитывать, что любой компонент или соединяющая сеть могут выйти из строя.

Процесс выполнения глобальной транзакции использует двухфазное подтверждение (2PC). Это происходит после выполнения действий, выполненных ветвями глобальной транзакции.

На первой фазе все ветви готовятся. То есть, TM говорит им подготовиться к подтверждению. Как правило, это означает, что каждый RM, который управляет ветвью, записывает действия для ветви в стабильное хранилище. Ветви указывают, могут ли они сделать это, и эти результаты используются для второй фазы.
На второй фазе TM сообщает RM, подтвердить или отменить. Если все ветви указали при подготовке, что они могут подтвердить, все ветви получают указание подтвердить. Если любая ветвь при подготовке указала, что она не может подтвердить, всем ветвям даётся указание отменить.

В некоторых случаях глобальная транзакция может использовать однофазное подтверждение (1PC). Например, когда менеджер транзакций обнаруживает, что глобальная транзакция состоит только из одного транзакционного ресурса (то есть одной ветви), этому ресурсу можно одновременно сказать подготовиться и подтвердить.