11.3. Типы репликации

1. Репликация моментальных снимков (snapshot replication) — тип репликации, когда информация на подписчике через определенные интервалы времени перезаписывается информацией с издателя. Никакого отслеживания происходящих изменений при этом не происходит. Этот тип репликации обычно используется в ситуации, когда нужно передавать небольшой объем данных, и эти данные изменяются достаточно сильно.

2. Репликация транзакций (transactional replication) — при использовании этого типа репликации вначале к подписчику применяется моментальный снимок исходных данных с издателя («инициализация» подписчика), а затем через определенные интервалы подписчику передается и применяется информация об произошедших на издателе изменениях — транзакциях. Для репликации транзакций предусмотрены специальные подтипы, которые позволяют настроить режимы репликации, отличные от стандартного:

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

• немедленное извещение об изменениях (immediate updating). При выборе этого режима должно существовать постоянно доступное сетевое соединение между издателем и подписчиком;

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

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

1. Репликация слиянием (merge replication) — при использовании этого типа репликации изменения можно вносить как на издателе, так и на подписчиках. Все изменения с помощью триггеров сводятся воедино на издателе, который разрешает конфликты в случае их возникновения. Для разрешения конфликтов репликации можно определить свою собственную программную логику. Затем итоговый вариант данных передается подписчикам.

11.4. Подготовка к настройке репликации

1. Определиться с типом репликации и теми данными, которые будут реплицироваться.

2. Принять решение относительно ролей серверов, которые будут участвовать в репликации. При назначении ролей серверам в основном во внимание нужно принимать:

• загрузку сервера;

• топологию сети;

• удобство администрирования.

Произвести проверку используемых форматов символьных данных на серверах-участниках репликации.

Определиться, какие объекты базы данных издателя должны игнорироваться при репликации (внешние ключи, условия на значение, триггера, столбцы счетчика), воспользовавшись параметром NOT FOR REPLICATION.

В случае использования репликации слиянием необходимо:

• в каждой таблице или представлении создать столбец типа uniqueidentifier, для возможности уникально идентифицировать каждую реплицируемую запись.

• поместить команды WRITETEXT или UPDATETEXT (для работы с данными text, ntext и image) в явно объявленные транзакции. Кроме того, для команд WRITETEXT и UPDATETEXT должен обязательно использоваться параметр WITH LOG — иначе информация о таких операциях не будет занесена в журнал транзакции и, соответственно, не будет отреплицирована.

• при выполнении операций массовой вставки данных использовать параметр FIRE_TRIGGERS для утилиты bcp или команды BULK INSERT.

Подумать о требованиях к дисковому пространству.