13.3.7 XA-транзакции
Поддержка транзакций доступна для InnoDB системы хранения. Реализация XA в MySQL основана на документе X/Open CAE Обработка распределенных транзакций: Спецификация XA. Этот документ опубликован The Open Group и доступен по адресу http://www.opengroup.org/public/pubs/catalog/c193.htm. Ограничения текущей реализации XA описаны в разделе 13.3.7.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), где действия, которые включают несколько серверов, должны происходить как часть глобальной транзакции, а не как отдельные транзакции, локальные для каждого сервера.
Банк хранит информацию об счетах в СУБД и распределяет/получает деньги через банкоматы (ATM). Необходимо убедиться, что действия ATM правильно отражаются в учетных записях, но это нельзя сделать только с помощью СУБД. Управляющая система глобальных транзакций интегрирует ресурсы банкомата и базы данных, чтобы обеспечить общую согласованность финансовых операций.
Приложения, которые используют глобальные транзакции, включают один или несколько менеджеров ресурсов и менеджера транзакций:
Менеджер ресурсов (RM) предоставляет доступ к транзакционным ресурсам. Сервер базы данных — один из видов менеджера ресурсов. Должно быть возможным либо подтвердить, либо откатить транзакции, управляемые RM.
Менеджер транзакций (TM) координирует транзакции, которые являются частью глобальной транзакции. Он взаимодействует с RM, которые обрабатывают каждую из этих транзакций. Отдельные транзакции внутри глобальной транзакции являются “ветвями” глобальной транзакции. Глобальные транзакции и их ветви идентифицируются по схеме именования, описанной позже.
Реализация XA в MySQL позволяет серверу MySQL действовать как менеджеру ресурсов, который обрабатывает XA-транзакции в рамках глобальной транзакции. Программа клиента, подключающаяся к серверу MySQL, действует как менеджер транзакций.
Для выполнения глобальной транзакции необходимо знать, какие компоненты участвуют, и привести каждый компонент к состоянию, когда он может быть подтвержден или отменен. В зависимости от того, что каждый компонент сообщает о своей возможности преуспеть, все они должны быть подтверждены или отменены как атомная группа. То есть, либо все компоненты должны быть подтверждены, либо все компоненты должны быть отменены. Для управления глобальной транзакцией необходимо учитывать, что любой компонент или соединяющая сеть могут выйти из строя.
Процесс выполнения глобальной транзакции использует двухфазный протокол подтверждения (2PC). Это происходит после выполнения действий, выполненных ветвями глобальной транзакции.
На первой фазе все ветви готовятся. То есть, им сообщается TM, чтобы они подготовились к подтверждению. Как правило, это означает, что каждый RM, который управляет ветвью, записывает действия для ветви в стабильное хранилище. Ветви указывают, могут ли они это сделать, и эти результаты используются на второй фазе.
На второй фазе TM сообщает RM, подтвердить или отменить. Если все ветви указали при подготовке, что они могут быть подтверждены, всем ветвям сообщается о подтверждении. Если какая-либо ветвь указала при подготовке, что она не может быть подтверждена, всем ветвям сообщается об отмене.
В некоторых случаях глобальная транзакция может использовать однофазный протокол подтверждения (1PC). Например, когда менеджер транзакций обнаруживает, что глобальная транзакция состоит только из одного транзакционного ресурса (то есть одной ветви), этому ресурсу можно сообщить о подготовке и подтверждении одновременно.
© 2025 Oracle
Licensed under the GPLv2 License.