Алгоритм, иллюстрирующий 2-ой подход

Узел, для которого получается новая реплика (Узел N), вовлекается в выполнение распределенных транзакций. Для каждого запроса на проведение распределенной транзакции он подтверждает выполнение своей части, реально не выполняя никаких действий. Далее он рассылает всем узлам сообщение на получение глобального состояния. Каждый узел, получив это сообщение, выполняет те же действия, что и в алгоритме 2. Завершив формирование свой части глобального состояния, каждый из узлов посылает его узлу N. Узел N получит, таким образом, два сообщения от каждого из остальных узлов: 1-ое после того как узел сохранит свое локальное состояние (посылается при 1-ом действии по алгоритму 2) и 2-ое, содержащее часть глобального состояния (посылается при 2-ом действии по алгоритму 2). После получения 1-ого сообщения от некоторого узла M, узел N начинает протоколировать все последующие сообщения от этого узла, до тех пор пока не получит сообщение 2 от всех узлов. После этого узел N имеет в своем распоряжении глобальное состояние и список сообщений от каждого из узлов, которые были посланы узлу N, после сохранения ими своего локально состояния. Этих данных достаточно, чтобы получить новую непротиворечивую реплику.

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

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

Сравнение механизмов репликации в ms sql Server 2005 и oracle Server 10g

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

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

Известны стратегии синхронизации данных, которые исключают возможность возникновения конфликтов, например, синхронная репликация в Oracle, или применение распределенных транзакций в MS SqlServer. Конфликты не могут возникать, потому что изменения происходят одновременно во всех репликах. Однако реализация этих стратегий требует наличие постоянных, надежных, скоростных каналов связи между узлами репликации, что приводит к существенному снижению уровня автономности каждого из узлов. Чтобы повысить уровень автономности каждого из узлов применяются другие стратегии, например, "репликация слияния" в MS SqlServer и "асинхроннаярепликации на уровне строк" в Oracle.

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

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

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

В Oracle и MS SqlServer существуют разные способы диагностики изменений в атрибутах. В Oracle используется сравнение текущего значения на изменяемом узле с эталонным, расположенном на узле, инициирующем обновление. Если эти значения различаются, то фиксируется конфликт. В MS SqlServer для определения изменений используются множественные версии данных атрибутов, которые сравниваются при каждом сеансе синхронизации.Конфликт фиксируется при различии в версиях данных. Сами версии хранятся в специальных таблицах.

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