РЕПЛИКАЦИЯ ДАННЫХ И УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ В РАСПРЕДЕЛЕННЫХ БАЗАХ ДАННЫХ

Для пользователя размещение данных в распределенной системе должно быть прозрачным. Данные могут быть разделены в РБД путем хранения различных таблиц на разных узлах или даже хранения разных фрагментов одной таблицы на разных узлах.

Репликация — это поддержание двух и более идентичных копий (реплик) данных на разных узлах РБД. Реплика может включать всю базу данных (полная репликация), одно или несколько взаимосвязанных отношений или фрагмент отношения [5, с.101]. Распределенные системы базы данных обычно являются реплицируемыми. Причины репликации[4, с.78]:

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

К основным достоинствам механизма репликации можно отнести повышение доступности и надежности данных и повышение локализации ссылок на реплицируемые данные. Основным недостатком репликации является сложность поддержания идентичности реплик: если в одну копию данных вносятся изменения, то эти изменения также должны быть внесены в другие копии. Это называется распространение изменений и реализуется службой тиражирования[3, с.59].

Для повышения производительности, система может выполнить:

• синхронную репликацию, или
• асинхронную репликацию.

В синхронной репликации изменения во все копии вносятся в рамках одной транзакции. В асинхронной репликации только часть реплик обновляется. Другие копии не обновлены после фиксации транзакции. Синхронная репликация называется «eager» репликация, а асинхронная репликация — «lazy» репликация.

Как правило, методы репликации могут быть организованы в соответствии со следующими тремя параметрами, которые определяют характер и свойства протокола репликации: архитектура сервера, взаимодействие сервера, и прекращение транзакции [1, с.120].

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

• репликация с основной копией,
• симметричная репликация.

Основной копией репликации необходимо иметь определенный сайт (primary сору), связанный с каждого элемента данных. Любое обновление для элемента данных сначала должно быть отправлено на основную копию. Затем основная копия передаёт обновление всем остальным сайтам. Репликация с основной копией может прерваться в случае отказа сайта с основной копией и вызвать «пробку». Эти ограничения могут быть решены путем применения более сложного протокола. Таким образом, если основная копия стала аварийной, один из других серверов берет на себя роль основной копии. Кроме того, чтобы избежать «пробки» многие системы распределенных баз данных состоят из нескольких разделов, и весь набор данных не реплицируется во всех репликах.

Симметричная репликация позволяет обновлять данные из любого места (сайта) системы. Все копии реплицируемого набора могут обновляться одновременно и независимо друг от друга, но все изменения одной копии должны попасть во все остальные копии[4, с.39]. То есть, обновления могут одновременно прийти на две различные копии одного и того же элемента дан­ных. Хотя симметричная репликация решает проблемы с единой точкой отказа и «пробки», осуществление такого подхода является сложной задачей.

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

Как правило, протоколы обмена одного сообщения за транзакцию выполняются путем группирования всех операций в одном сообщении. Постоянное взаимодействие обычно использует преимущества концепции транзакции. Так как транзакции могут содержать одну операцию или несколько операций, но идея заключается в создании одного сообщения для каждой транзакции, а не генерации сообщений на основе каждой операции. Линейное взаимодействие, которое обычно соответствует методам, где сервер баз данных распространяет каждой операции транзакции в расчете «per operation». Операции могут быть отправлены либо в виде SQL программы или записи журнала, содержащего результаты выполненной операции в конкретном сервере. Линейное взаимодействие работает в небольшой минимальной среде узлов, но когда он применяется в больших распределенных системах тысячи узлов, ограничена масштабируемость.

Здесь учитывается метод прекращения транзакций. Важно, чтобы координировать все реплики, когда транзакция была получена на сайте, для того, чтобы обеспечить атомарность при прекращении транзакции. Прекращение транзакции не так важно для производительности, как взаимодействие серверов, но оно может влиять на производительность репликации данных, доступность, и, самое главное целостности данных. Протокол прекращения транзакции — это процесс, посредством которого все серверы будут согласованы, чтобы либо прервать, либо совершить транзакции. Некоторые протоколы обеспечивают полную атомарность, но другие могут предложить лишь частичную атомарности. Кроме того, некоторые протоколы могут использовать один менеджер транзакций для управления прекращением транзакции, а некоторые протоколы могут использовать несколько менеджеров транзакций, это просто зависит от реализации. Прекращение транзакции может быть выполнено двумя разными способами: голосованное прекращение (Voting Termination) и прекращение без права голоса (Non-Voting Termination)[5, с.45]. Голосованное прекращение (Voting Termination) требует дополнительного раунда сообщения для координации различных реплик. Этот раунд может быть столь же сложным, как протокол атомной фиксации (например, протокол двухфазной фиксации (2ФФ)), или же простой, как одно сообщение с подтверждением. Прекращение без права голоса (Non-Voting Termination) предполагает, что сайты могут решить самостоятельно: зафиксировать или прервать транзакцию. Репликация без права голоса (Non-Voting Replication) часто называют ленивой репликацией. Её главным преимуществом является то, что она не блокирует сайты. Однако, репликация без права голоса не блокирует за счет согласованности данных.

Транзакция является единицей атомарности и согласованности, которая обеспечивает сохранение целостность данных в условиях параллельного доступа и сбоев системы. Транзакция — это логическая единица работы. Транзакции обладают четырьмя важными свойствами: атомарность, согласованность, изоляция и долговечность [4, с.69].

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

Распределенная транзакция обращается к объектам, которые управляются несколькими распределенными серверами. Во многих СУБД были решения для транзакции целевой распределенной базы данных. Так как приложения становятся все более и более отделены от баз данных, требование поддержки транзакций на уровне приложений возрастает. Классическая модель для распределенных транзакций на уровне базы данных и на уровне приложений использует один координатор транзакций, а также несколько менеджеров ресурсов (участников). Несмотря на то, что однофазный протокол хорошо подходит для одной машины, он недостаточен для распределенных транзакций. Причина здесь в том, что однофазный протокол не может работать с подмножеством прерываний участников после решения о фиксации координатора. Чтобы удовлетворить требования атомарности, обработки транзакций распределенных систем используют протокол двухфазной фиксации для того, чтобы достичь соглашения на глобальный результат транзакции.

В протоколе двухфазной фиксации транзакция выполняется в два этапа: этап голосования и этап принятия решения. На этапе голосования координатор транзакции просит всех участников транзакции, готовы ли они зафиксировать результаты локальных субтранзакций. Если координатор транзакции получает подтверждение от каждого из участников, он приступает к этапу принятия решения. На этапе принятия решения координатор транзакции указывает участникам, совершить или откатить все изменения, которые были запрошены в качестве части транзакции. Определения для различных элементов 2ФФ приводятся ниже.

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

Ниже перечислены шаги, которые участвуют в завершение распределенной транзакции [2, с.67].

1. Координатор транзакций сначала проверяет, работают ли Менеджеры транзакций на всех узлах, участвующих в транзакции. Если один из них не работает, то координатор транзакций возвращает сообщение об ошибке и не начинает распределенную транзакцию.
2. Если все Менеджеры транзакций являются доступными, Координатор транзакций формирует распределенной идентификатор транзакции и связывает идентификатор со всеми участниками этой конкретной транзакции.
3. Когда приложение будет готово совершить все изменения в менеджерах ресурсов, участвующих в распределенной транзакции, все узлы в транзакции должны выполнять обе фазы: фаза голосования и фаза принятия решения.
4. В фазе голосования координатор транзакций спрашивает каждого менеджера ресурсов, участвующего в транзакции, готов ли он зафиксировать транзакцию. Если координатор получает ответ «да» от всех менеджеров ресурсов, он переведет участников транзакции в фазу фиксации.
5. В фазе фиксации координатор транзакций указывает менеджерам ресурсов сделать постоянными изменения в своих данных, т.е. зафиксировать изменения. Менеджеры ресурсов затем фиксируют изменения и транзакция будет завершена.

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

Список литературы:

1. Бертсекас Д., Галлагер Р. Сети передачи данных. — М.: Мир,2009.-544 с
2. Бутрименко A.B. Разработка и эксплуатация сетей ЭВМ. — М.:Финансы и статистика, 2011. — 256с.
3. Игнатьев В.М., Ларкин Е.В. Анализ производительности ЭВМ//Учеб. пособие,- Тула: ТулГТУ, 2009. -104 с.
4. Задков В.П., Пономарев Ю.В. Компьютер в эксперименте. Архитектура и программные средства систем автоматизации. — М.: Наука, 2002. -376с.
5. Таненбаум Э., Ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2008 — 845с.[schema type=»book» name=»РЕПЛИКАЦИЯ ДАННЫХ И УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ В РАСПРЕДЕЛЕННЫХ БАЗАХ ДАННЫХ» author=»Власенко Сергей Валерьевич» publisher=»БАСАРАНОВИЧ ЕКАТЕРИНА» pubdate=»2017-05-26″ edition=»ЕВРАЗИЙСКИЙ СОЮЗ УЧЕНЫХ_ 30.01.2015_01(10)» ebook=»yes» ]