Способы управления транзакциями в распределенных ис. Механизм двухфазной фиксации транзакций.

Управление транзакциями – один из важнейших аспектов при создании надежных распределенных систем, хотя в различных технологиях создания таких систем степень универсальности управления транзакциями может существенно варьироваться. Примером вполне жизнеспособного, но все же упрощенного решения может служить схема управления транзакциями в COM+ – за счет предположения о том, что COM-объекты не имеют состояния и создаются заново для каждой новой транзакции.

Что вообще понимается под транзакцией в распределенной системе?

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

Распределенная система является совокупностью взаимодействующих объектов, в общем случае имеющих состояния. Важнейшим отличием распределенных (многозвенных) систем от классических клиент-серверных приложений является то, что при начале транзакции в принципе неизвестно, сколько объектов, состояние которых нужно сохранять или восстанавливать по обычным правилам транзакций, принимают в этой транзакции участие. Клиент, посылающий запрос серверному объекту, в общем случае не знает, какую цепочку вызовов (и к каким объектам) породит этот единственный запрос. О цепочке вызовов в целом не имеет представления ни один из участвующих в ней объектов.

Попытки создания универсальной модели управления транзакциями предпринимались неоднократно. Наибольший успех выпал на долю модели Distributed Transaction Proccessing Model (DTP, иногда используется аббревиатура DTM) консорциума X/Open (в настоящий момент – Open Group).

Модель DTP

Здесь будет рассмотрен упрощенный вариант DTP (исключая так называемые Менеджеры Коммуникационных Ресурсов – Communication Resource Managers, CRM). Согласно этой модели, участниками транзакционной распределенной системы являются:

• Прикладная программа (программы). Это одно или несколько приложений, реализующих бизнес-логику распределенной системы.

• Менеджер Транзакций (Transaction Manager, TM). Это приложение, управляющее выполнением транзакций в распределенной системе. TM не начинает и не завершает транзакции – это задача прикладной программы.

• Менеджер Ресурсов (Resource Manager, RM). Это одно или нескольких приложений, обеспечивающих сохранение и восстановление состояний участвующих в транзакции объектов. Концептуально RM выполняет ту же роль, что и, например, CУБД.

Эти три участника должны, естественно, «общаться» между собой в процессе функционирования системы. Для формализации такого взаимодействия DTP определяет два стандартных протокола:

• Интерфейс TX. Этот интерфейс содержит методы, с помощью которых обращаются друг к другу прикладная программа и Менеджер Транзакций, например, tx_begin(), tx_commit() и tx_rollback(). Вызывая эти (и некоторый другие методы), прикладная программа инициирует процессы инициации и завершения транзакций. Реальное управление транзакциями выполняются Менеджером Транзакций.

• Интерфейс XA. Этот интерфейс определяет протокол взаимодействия Менеджера Транзакций и Менеджера Ресурсов. Часть вызовов порождается Менеджером Транзакций, например, xa_start() или xa_commit(), часть – Менеджером Ресурсов (ax_reg(), который нужен для сопоставления конкретного Менеджера Ресурсов с конкретной транзакцией).

Протокол взаимодействия прикладной программы и Менеджера Ресурсов не определен в модели DTP. Если вашей программе нужно напрямую обращаться к RM, это можно сделать произвольным образом (например, через SQL).

Схематически взаимодействие участников можно показать следующим образом:

Двухфазная фиксация транзакций

Многие, взглянув на такую задачу, сразу же подумают о распределенных транзакциях. Другими словами, это означает синхронизацию двух субтранзакций с помощью протокола двухфазной фиксации транзакций. Это решение проиллюстрировано на рисунке:

Я называю эти диаграммы диаграммами «задача/сообщение». Они похожи на диаграммы последовательностей в языке UML (универсальный язык моделирования), но я также показываю пользователей и основные обновления данных. Они предназначены для анализа потенциальных проблем в системе — прежде всего, связанных с выполнением и восстановлением. Приложение обновления кассы во многих банках физически расположено в отделениях. Однако в банке Woodgrove оно размещено централизованно в центре обработки данных банка.

На практике при использовании двухфазной фиксации транзакций могут возникнуть три проблемы.

• Во-первых, снижение производительности. Становится больше сообщений, передаваемых по сети, а ресурсы в приложении обновления счета должны оставаться заблокированными вплоть до выполнения фиксации транзакции.

• Вторая практическая проблема заключается в том, что решение с двухфазной фиксацией транзакций надежно лишь настолько, насколько надежно ее самое надежное звено и сеть между ними.

• Третья практическая проблема – не всякое программное обеспечение поддерживает двухфазную фиксацию транзакций. Интерфейс запускаемых приложений ее не поддерживал, и (на момент выполнения этого проекта) в веб-сервисах тоже не было такой поддержки. Осуществление такого метода означало бы необходимость введения нового ПО промежуточного слоя, что привело бы к необходимости внесения изменений в прикладные программы.

35. Журнализация, контрольные точки как средство восстановления информации в КИС.

Журнализация транзакций

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

В простейшем случае журнализация изменений заключается в последовательной записи во внешнюю память всех изменений, выполняемых в базе данных. Записывается следующая информация:

порядковый номер, тип и время изменения;

идентификатор транзакции;

объект, подвергшийся изменению (номер хранимого файла и номер блока данных в нём, номер строки внутри блока);

предыдущее состояние объекта и новое состояние объекта.

Формируемая таким образом информация называется журнал изменений базы данных. Журнал содержит отметки начала и завершения транзакции, и отметки принятия контрольной точки (см. ниже).

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

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

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

В случае логического отказа или сигнала отката одной транзакции журнал сканируется в обратном направлении, и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Согласно извлеченной информации выполняются действия, отменяющие действия транзакции, а в журнал записываются компенсирующие записи. Этот процесс называется откат (rollback).

В случае физического отказа, если ни журнал, ни сама база данных не повреждена, то выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнется сначала, но фактически восстановление продолжиться с той точки, откуда оно прервалось.

Реализации

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

Oracle

В СУБД Oracle журнал изменений разделен на журнал повтора и журнал отката. В журнал повтора записывается только информация, о том, в каком состоянии объект находился после выполнения изменения. Эта информация не может быть применена для отката отдельной транзакции.

Информация для отката (журнал отката) группируется в сегменты отката и также используется для поддержания целостности по чтению. В случае подтверждения транзакции информация о старых данных уничтожается, а в случае отката — используется для восстановления отменяемой транзакции.

Informix

В СУБД Informix журнал изменений представляет из себя дисковое пространство, разделенное на части называемые файлами журнала транзакций (эти файлы не имеют ничего общего с файлами на файловой системе) или логическим журналом. Запись изменений в этот журнал зависит от того в каком режиме находится база данных — без журналирования, с буферизованным журналированием или с небуферизованным. Все изменения сначала попадают в буфера логического журнала, а дальнейший сброс их в журнал транзакций зависит от режима журналирования базы данных.

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

Контрольная точка — служебная информация, которая записывается операционной системой на жесткий диск или другой носитель для обработки исключительных ситуаций, таких как перезапуск, сбой или отказ оборудования. По состоянию контрольной точки операционная система может определить был сбой или нет и восстановить данные, вычислительные потоки. При этом часть данных между последней записью контрольной точки до сбоя теряются. При решении объемных задач контрольные точки эффективно восстанавливают процесс вычисления и помогают избежать полного перезапуска.

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