Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 79

Репликация транзакций

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

В SQL Server 2005 первоначальное тиражирование происходит по схеме репликации моментальных снимков с использованием агентов Snapshot Agent и Distribution Agent. После этого запускается агент Log Reader Agent, который устанавливает соединение с издателем, регулярно просматривает журнал транзакций, осуществляя поиск записей о модификации реплицируемых данных. Найденные транзакции регистрируются в БД распределения. За их копирование отвечает агент Distribution Agent.

Стандартная схема репликации транзакций допускает обновление данных только на издателе, а подписчики могут получать копии обновляемых данных. Однако в SQL Server 2005 реализованы также нестандартные схемы, благодаря которым репликация транзакций становится похожей на репликацию сведением. Репликацию транзакций можно настроить так, чтобы изменения данных были возможны как на издателе, так и на подписчиках. При этом подписчики могут немедленно извещать издателя об изменениях (для этого требуется постоянное сетевое соединение между узлами), либо передавать информацию об изменениях через определенные интервалы времени с использованием специальных очередей. В последнем случае система репликации дополняется еще одним участником – агентом Queue Reader Agent. Его задача состоит в том, чтобы считывать из очереди сообщения о завершении транзакций на подписчиках и предавать их издателю для выполнения различных операций.

Репликация сведением

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

При репликации сведением работают два агента:

·  Snapshot Agent – выполняет подготовку моментальных снимков и других файлов, необходимых для начальной синхронизации подписчика с издателем;

·  Merge Agent – объединяет изменения, сделанные на всех участниках репликации, в единую структуру, и распространяет их на все узлы сети.

Агент Merge Agent запускается на стороне дистрибьютора (в случае принудительной репликации) или на стороне подписчика (в случае репликации по запросу).

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

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