Меню

Координатор распределенных транзакций настройка



Настройка координатора транзакций по умолчанию

По умолчанию каждая система использует свой локальный диспетчер транзакций службы DTC (Distributed Transaction Coordinator) для инициирования и согласования транзакций. Однако можно настроить компьютер на использование диспетчера транзакций службы DTC другой системы в качестве координатора транзакций по умолчанию. Диспетчер транзакций DTC в заданной системе используется как координатор транзакций каждый раз, когда клиент в локальной системе начинает транзакцию DTC и не указывает в явном виде координатор транзакций. Координатор транзакций по умолчанию согласовывает все транзакции, которые инициируются службой COM+ или любым другим клиентом, использующим транзакции. Координатор транзакций по умолчанию также функционирует как координатор транзакций для всех диспетчеров ресурсов в локальной системе, которые вовлечены в какую-либо транзакцию DTC.

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

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

Для выполнения этой процедуры необходимо входить в группу администраторы или обладать эквивалентными разрешениями. Дополнительные сведения см. в подразделе «Дополнительная информация» данного раздела.

Чтобы назначить удаленную систему в качестве координатора транзакций по умолчанию

Откройте оснастку «Службы компонентов».

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

В диалоговом окне свойств компьютера перейдите на вкладку MSDTC.

Снимите флажок использовать локальный координатор.

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

Нажмите кнопку ОК.

Дополнительная информация

  • Оснастка «Службы компонентов» больше не входит в группу «Администрирование». Чтобы открыть оснастку «Службы компонентов», нажмите кнопку Пуск. В текстовом поле введите команду dcomcnfg и нажмите клавишу ВВОД.

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

Чтобы назначить локальную систему в качестве координатора транзакций по умолчанию

Откройте оснастку «Службы компонентов».

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

В диалоговом окне свойств компьютера перейдите на вкладку MSDTC.

Установите флажок использовать локальный координатор.

Нажмите кнопку ОК.

Дополнительная информация

  • Оснастка «Службы компонентов» исключена из компонента «Администрирование». Чтобы открыть оснастку «Службы компонентов», нажмите кнопку Пуск. В текстовом поле введите команду dcomcnfg и нажмите клавишу ВВОД.

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

Источник

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

Координатор распределённых транзакций (DTC) — компонент Microsoft Windows, предназначенный для координации изменения данных на двух или более сетевых компьютерных системах.

Координатор распределённых транзакций основан на технологии COM+ и включает в себя:

  • менеджер транзакций;
  • журнал транзакций;
  • прокси (реализует интерфейсы DTC);
  • утилиты администрирования;
  • заголовочные файлы API.

Выполнение распределённых транзакций Править

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

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

Читайте также:  Настройки для усилителя фьюжен

Источник

Блог Александра Кондуфорова

об информационных технологиях, программировании, путешествиях и фотографии

Monday, December 26, 2011

Распределенные транзакции (Distributed Transactions) и их настройка

Каждый программист, работающий с данными, сталкивался с обычными транзакциями той или иной базы данных. Основная задача транзакций – обеспечить consistency данных после завершения операции: изменения либо успешно сохраняются от начала и до конца, либо полностью откатываются, если что-то пошло не так. Даже если вы ни разу не писали в SQL коде ключевые слова BEGIN TRAN, COMMIT TRAN или ROLLBACK TRAN или нечто подобное, это еще не значит, что вы их не использовали. Все ORM, реализующие паттерн unit of work (Entity Framework, NHibernate и др.) объединяют операции по изменению данных в транзакцию перед сохранением.

Транзакции хорошо работают в рамках одной базы данных, но если у вас распределенная система, которая требует сохранения данных в разных базах на разных серверах, а иногда и платформах, то нужна более тяжелая артиллерия – распределенные транзакции (distributed transactions, DT).

Перед тем, как начать работать с распределенными транзакциями, нужно изучить механизм их работы, протоколы и особенности, которые не так просты. Очень хорошее описание темы есть в этой статье, где дается отличное общее понимание и практические примеры, просто must read:

Работа вложенных транзакций отлично расписана здесь:

Также не забывайте про MSDN:

Итак, .NET поддерживает распределенные транзакции при помощи класса TransactionScope . Кроме этого, основная технология разработки распределенных приложений, WCF, также поддерживает распределенные транзакции из коробки, предоставляя программисту целый комплекс конфигурационных параметров и атрибутов, которые позволяют с легкостью превратить ваш сервис из обычного в распределенно-транзакционный.

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

1) Сконфигурировать WCF для поддержки DT

Распределенные транзакции не поддерживаются в режиме basicHttpBinding , поэтому нам нужно использовать хотя бы на wsHttpBinding , в binding которого нужно прописать атрибут transactionFlow=”true” :

2) Установить специальные атрибуты в интерфейсе сервиса и его методов

Необходимо добавить атрибуты TransactionFlow для метода в контракте и свойства атрибута OperationBehavior TransactionScopeRequired и опционально TransactionAutoComplete в реализации метода:

Атрибут TransactionFlow принимает несколько опций: Allowed обозначает, что метод сервиса может вызываться как из кода, обернутого в TransactionScope , так и из обычного. Mandatory требует наличия TransactionScope , а NotAllowed (по умолчанию) заставит сервис игнорировать транзакции на клиенте вообще.

3) Создать на стороне клиента транзакцию, внутри которой вызвать метод WCF сервиса

Выглядит это приблизительно так:

Безусловно, в вашем коде вызов сервиса должен находиться в отдельном классе, это лишь пример.

TransactionOptions позволяет задать некоторые параметры транзакции. В нашем случае это уровень изоляции (значение по умолчанию Serializable не рекомендуется из-за опасности возникновения дедлоков) и таймаут операции (5 минут).

При создании TransactionScope мы указываем параметр TransactionScopeOption.RequiresNew , что не позволит никакому другому коду обернуть наш метод в свою транзакцию. Подробнее вложенные транзакции описаны здесь.

Внутри TransactionScope в случае, если мы действительно хотим закоммитить транзакцию, мы делаем вызов scope.Complete() . Если нам нужно транзакцию откатить (как в случае с catch в примере), мы просто не вызываем Complete() . Вызывать Complete() нужно после всех клиентских операций с базой данных, которые происходят внутри транзакции, иначе у вас случится ошибка, что connection или provider уже закрыт.

Обратите внимание, что в коде сервиса из предыдущего пункта нет никакого намека на TransactionScope , кроме атрибутов TransactionFlow и OperationBehavior . Он там и не нужен, для стандартного сценария атрибутов достаточно. Однако никто вам не мешает создавать свои вложенные транзакции, как с опцией Required (используем родительскую транзакцию), так и с опциями RequiresNew (новая независимая транзакция) и Suppress (код не будет выполнятся в родительской транзакции).

Читайте также:  Настройка пульта rm f04

4) Запустить сервис и клиент

И вуаля – все работает. Или не работает? Говорите, полезли странные ошибки выполнения?

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

1) Убедиться, что на всех клиентах и серверах (здесь и далее — включая сервера баз данных и веб-сервера) установлена и запущена служба Distribution Transactions Coordinator. Именно эта служба отвечает за координацию ваших распределенных транзакций.

2) Убедиться, что на всех клиентах и серверах включена поддержка распределенных транзакций. Для этого запускаем Control Panel –> Administrative Tools –> Component Services, идем в Computers –> My Computer –> Distributed Transaction Coordinator –> Properties (контекстное меню) и устанавливаем на вкладке Security следующие параметры:

  • Network DTC Access
  • Allow Remote Clients
  • Allow Inbound
  • Allow Outbound

3) Разрешить работу Distributed Transactions Coordinator во всех установленных брандмауэрах, включая Windows Firewall:

4) Убедиться, что все ваши клиенты и сервера находятся в одной локальной сети. В большинстве случаев так оно и есть, но есть исключения, и если вы тот самый счастливчик, то вам придется немного попотеть, реализовывая поддержку протокола WS-Atomic Transaction (WS-AT), который упоминается в общей статье. Если вы тот самый счастливчик, которому надо начинать настраивать WS-AT, то вот еще пара полезных статей:

5) Для работы DTC по локальной сети: все машины должны пинговаться по netbios-имени.

6) Важно: Если вы пошли по нашему пути и запустили тестовую конфигурацию на виртуальных машинах, запущенных с одного образа: переустановить DTC. DTC не работает с одинаковыми CID, а переустановка их сбрасывает. Это проблема, с которой мы столкнулись и которую смогли найти лишь запустив утилиту DTCPing.

7) Если ничего не помогло: поставить и запустить DTCPing и посмотреть, что она говорит. Очень хороший способ, когда ничего другое не помогает:

Источник

Распределенные транзакции для разнородных баз данных в MS .NET

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

  1. Одной транзакции.
  2. Это могут быть несколько разнообразных баз данных таких как Oracle, MS SQL Server и PostgreSQL.
  3. Отклик на CRUD операцию может быть значительным.
  4. Последовательность вставки не важна.

Чего коллеги добивались задавая этот вопрос? Проверить мой опыт или получить готовое решение? На самом деле для меня не важно, но вот что важно — задача в теории вопроса показалась мне интересной и, я решил написать статью о том, как можно было бы решить эту задачу.

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

Опция №1. Приложение С++ и ODBC драйвер (вызов Координатора распределенных транзакций Microsoft (MSDTC) для SQL Server по-владению)

Координатор распределенных транзакций Microsoft (MSDTC) позволяет приложениям расширять или распределять транзакции по двум или более экземплярам SQL Server. Распределенная транзакция работает, даже если два экземпляра размещены на разных компьютерах.

MSDTC работает для Microsoft SQL Server только локально, и недоступен для облачной службы базы данных Microsoft Azure SQL.

MSDTC вызывается драйвером собственного клиента SQL Server для Open Database Connectivity (ODBC), когда ваша программа C++ управляет распределенной транзакцией. Драйвер ODBC для собственного клиента имеет диспетчер транзакций, совместимый со стандартом XA Open Distributed Transaction Processing (DTP). Это соответствие требуется MSDTC. Как правило, все команды управления транзакциями отправляются через этот драйвер ODBC для собственного клиента. Последовательность следующая:

Приложение ODBC для собственного клиента C ++ запускает транзакцию, вызывая SQLSetConnectAttr с отключенным режимом автоматической фиксации.
Приложение обновляет некоторые данные на SQL Server X на компьютере A.
Приложение обновляет некоторые данные на SQL Server Y на компьютере B.
В случае сбоя обновления на SQL Server Y все незафиксированные обновления в обоих экземплярах SQL Server откатываются.
Наконец, приложение завершает транзакцию, вызывая SQLEndTran (1) с параметром SQL_COMMIT или SQL_ROLLBACK.

(1) MSDTC может быть вызван без ODBC. В таком случае MSDTC становится менеджером транзакций, и приложение больше не использует SQLEndTran.

Читайте также:  Vray global switches настройки

Только одна распределенная транзакция.

Предположим, что ваше приложение ODBC для собственного клиента C ++ зачислено в распределенную транзакцию. Затем приложение зачисляется во вторую распределенную транзакцию. В этом случае драйвер ODBC собственного клиента SQL Server покидает исходную распределенную транзакцию и включается в новую распределенную транзакцию.

Подробнее о MSDTC можно прочитать тут.

Опция №2. Приложение C# как альтернатива для базы данных SQL в облаке Azur

MSDTC не поддерживается ни для базы данных SQL Azure, ни для хранилища данных SQL Azure.

Однако распределенную транзакцию можно создать для базы данных SQL, если ваша программа на C # использует класс .NET System.Transactions.TransactionScope.

В следующем примере показано, как использовать класс TransactionScope для определения блока кода для участия в транзакции.

Опция №3. Приложения C# и Entity Framework Core для распределенных транзакций.

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

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

Вы можете использовать API DbContext.Database для запуска, фиксации и отката транзакций. В следующем примере показаны две операции SaveChanges () и запрос LINQ, выполняемый в одной транзакции.

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

Если вы используете EF Core в .NET Framework, реализация System.Transactions там поддерживает распределенные транзакции.

Как видно из документации в рамках платформы и линейки продуктов Microsoft распределенные транзакции не проблема: MSDTC, облако само по себе отказоустойчиво, связка ADO .NET + EF Core для экзотических комбинаций (читать тут).

Как же нам поможет решить задачу обзор транзакций на платформе Microsoft? Очень просто, есть четкое понимание, что стандартного инструментария для реализации распределенной транзакции по разнородным базам данным в приложении .NET просто нет.

А раз так, то делаем собственный home-made координатор распределенных транзакций (КРТ).

Один из вариантов реализации это распределенные транзакции основанные на микросервисах (смотрим тут). Этот вариант не плох, но он требует серьезной доработки Web API для всех систем вовлеченных в транзакцию.

А потому, нам нужен немного другой механизм. Ниже приведен общий подход к разработке КРТ.

Как видно из схемы главной идеей является создание и хранение с обновляемым статусом записи транзакции хранящейся в мастер-базе (или таблице). Даная модель КРТ позволяет реализовать распределенные транзакции соответствующие требованиям:

  • атомарности
  • согласованности
  • изолированности
  • долговечности

КРТ — может быть частью приложения в которой пользователь сформировал запись, а может быть совершенно отдельным приложением в виде системного сервиса. КРТ может содержать специальный подпроцесс который, формирует транзакции в пул на исполнением при отключении электричества (на схеме не указано). Бизнес правила конвертирования (картирования) исходных данных сформированных пользователем для связанных БД могут быть динамически добавляемые и конфигурируемые через XML/JSON формат и храниться в локальной папке приложения, либо в записи транзакции (как вариант). Соответственно для этого случая целесообразно унифицировать конвертирование в связанные БД на уровне кода путем реализации модульности конвертеров в виде DLL. (И да, КРТ подразумевает прямой доступ к БД без участия Web API.)

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

Еще раз уточню что распределенная транзакция это по определению одномоментное сохранение информации без ее изменения, но с возможностью картирования в схемы данных различных баз данных. Так что если вам нужно при фиксировании инцидентов в приемном покое больницы (пулевое ранение) раскидывать в тот же момент времени данные по другим базам, например, в МВД, ФСБ и страховые компании, то данный подход вам безусловно поможет. Этот же механизм может прекрасно работать в финансовых учреждениях.

Надеюсь этот подход показался вам интересным, пишите что вы об этом думаете, коллеги и друзья!

Источник

Adblock
detector