1я лекция. Вводная (стр. 24 )

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

Синхронизация

Репликация посредством синхронизации предусматривает фиксацию в конкрет­ный момент времени текущего состояния и структуры данных публикации с после­дующей рассылкой этих сведений в адрес подписчиков. Синхронизация также впер­вые появилась в SQL Server 6.x и является имеющим наиболее простую организацию типом репликации. Поскольку передаваемые данные представляют собой копию ин­формации на определенный момент времени, нет необходимости беспокоиться о возникновении конфликтов или потере сведений об отдельных транзакциях. Приме­рами приложений и сценариев, в которых может успешно использоваться схема син­хронизации, являются справочные таблицы, содержимое которых изменяется отно­сительно редко, анонимные подписчики, таблицы со статической или редко изме­няемой информацией.

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

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

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

Непосредственно обновляемые подписчики

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

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

Согласованность транзакций

В контексте репликации данных согласованность транзакций означает, что на всех узлах данные будут иметь идентичные состояния, соответствующие тому, которое могло возникнуть при выполнении всех транзакций на одном и том же узле. Репликация вно­сит в процессы некоторый элемент случайности, который выражается в появлении оп­ределенных временных задержек между моментом выполнения изменения в данных и моментом репликации этих сведений подписчикам. В SQL Server 2000 задержки репли­кации относятся к одному из двух возможных вариантов согласованности транзакций: гарантированной неполной согласованности (guaranteed loose consistency) и гарантированно­му отсутствию согласованности (guaranteed no consistency).

Гарантированная неполная согласованность означает, что синхронизация данных между сервером-источником и сервером-получателем не выполняется немедленно. Прежде чем подробнее остановиться на этом варианте, рассмотрим еще одну модель распределенных данных — гарантированную точную согласованность (guaranteed tight consistency). Она может быть реализована в SQL Server с использованием двухступен­чатого протокола фиксации изменений. В этой модели все выполняемые транзакции либо фиксируются, либо отменяются одновременно на всех серверах, поэтому дан­ные всех серверов всегда синхронизированы на 100%.

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

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

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

База данных рассылки

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

Системные таблицы, входящие в состав базы данных рассылки.

• MSmerge_history — содержит информацию о выполненных ранее обновлениях подписчиков.

• MSmerge_agents — содержит сведения об агентах слияния.

• MSdistribution_agents — содержит сведения об агентах рассылки.

• MSdistribution_history — содержит информацию для агентов рассылки.

• MSlogreader agents — содержит сведения об агентах чтения журнала на локальном рассылающем сервере.

• MSlogreader_history — содержит информацию для агентов чтения журнала.

• MSrepl_commands — содержит команды репликации.

• MSrepl errors — содержит сведения о неудачных попытках выполнения про­

цедур репликации.

• MSrepl_transactions — содержит отдельную строку для каждой подлежащей

репликации транзакции.

• MSrepl version — содержит единственную строку со сведениями о версии те­

кущей установленной службы репликации.

Обзор агентов репликации SQL Server

Для эффективного управления работой системы репликации SQL Server необхо­димо подробно ознакомиться с различными агентами, используемыми в процессах репликации.

Все существующие типы агентов:

• Агент чтения журнала (log reader). Анализирует наличие в журнале транзакций публикуемой базы данных записей об отдельных транзакциях, подлежащих

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

• Агент слияния (merge agent). Отвечает за слияние поступающих изменений, а

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

агента синхронизации.

• Агент синхронизации (snapshot agent). Создает файлы синхронизации на рассылающем сервере и фиксирует в базе данных рассылки статус информации о

синхронизации между публикуемой базой данных и базами данных серверов-