По материалам статьи Paul Ibison: Log Shipping vs. Replication
Перевод Ирины Наумовой

Многие статьи о репликации и передаче журналов (Log Shipping) сконцентрированы в основном на том, как их настроить и сконфигурировать. В этой же статье описаны различия между ними. Log shipping и репликацию часто сравнивают с кластеризацией, однако кластеризация - это на самом деле технология, созданная чтобы обеспечить отказоустойчивость системы. Здесь имеются некоторые ограничения: расстояние между узлами ограничено и данные системы физически расположены в одном месте, поэтому нет возможности распределить запросы, чтобы например, использовать один из серверов для отчетности.
Также кластеризацию довольно трудно устанавливать и настраивать и необходимо иметь лицензию, которая стоит недешево. Поэтому многие DBA используют свой накопленный опыт для применения методологии, которая поддерживает резервный сервер, ввод которой для поддержания отказоустойчивости требует ручной настройки, но при этом появляется возможность использовать один из серверов для отчетности.
Обычно выбор останавливается между log shipping и репликацией, но нужно ясно представлять какой метод больше подходит. В таблице ниже представлены некоторые ключевые отличия, которые подробнее объясняются далее.

Вопрос	Log-Shipping	Replication
Каково время ожидания обновления?	>1min	Низкое, порядка нескольких секунд
Меняется ли схема на издателе?	Нет	Репликация моментальных снимков - нет Репликация транзакций - нет Репликация сведением или обновления подписчиков - да
Меняется ли схема на подписчике?	Нет	Возможно (смотри текст)
Есть ли требования к схеме?	Нет	Требуется первичный ключ на таблице
Есть ли возможность выбрать отдельные статьи?	Нет	Да
Доступна ли база на подписчике/резервном сервере?	Да	Нет
Передаются ли системные данные?	Часто	Да
Можно ли использовать сервер подписчик/резервный сервер для сбора отчетности?	Вряд ли (смотри текст)	Да

Каково время ожидания обновления?

Log shipping может производить резервное копирование не чаще чем раз в минуту, и с такой же частотой выгружать копию на резервный сервер. Если используется репликация транзакций или репликация сведением (merge), время ожидания обновлений может быть снижено до нескольких секунд, если параметр POLLINGINTERVAL Log Reader агента установлен минимальным. Репликация моментальных снимков (snapshot) будет иметь более длительное время ожидания обновлений, поскольку требует во время генерации снимка эксклюзивной блокировки на издателе реплицируемых таблиц, следовательно, такой вид репликации подходит только тогда, когда нет обращений к этим таблицам.

Меняется ли схема на издателе?

Log shipping и snapshot - репликация не изменяют схему на издателе. При обновлении подписчиков (репликация транзакций, репликация моментальных снимков) и репликации сведением нужно добавление уникальных столбцов, необходимых для идентификации баз данных и строк таблицы, типа uniqueidentifier, для которого установлено свойство rowguidcol. Если Вы реплицируете таблицу, не имеющую такого столбца, то SQL Server создаст его сам и назовет ROWGUID. В этом случае некоторые запросы на издателе могут возвращать ошибку, например, если внутри хранимой процедуры используется следующий запрос:

INSERT INTO ExistingTable
SELECT * FROM ReplicatedTable

Меняется ли схема на подписчике?

Log shipping не изменяет схему. Репликация моментальных снимков и репликация транзакций могут производить изменения в схеме; стандартные репликация моментальных снимков и репликация транзакций не передают атрибуты идентификаторов Identity, они становятся на подписчике простыми числовыми столбцами (int, smallint, numeric...).
Некоторые администраторы базы данных пробуют обойти это, используя асинхронную инициализацию и гарантируя, что таблица на подписчике имеет идентификатор с атрибутом Identity , который по существу позволяет процессу репликации делать вставки идентификатора, однако, для обеспечения отказоустойчивости сервера эта методология не подходит, т.к. внутренний счетчик для identity не увеличивается, и использование DBCC CHECKIDENT не будет работать на поле, созданном с этим атрибутом. Если выбрана репликация сведением или репликация с отложенным обновлением подписчиков, такой проблемы не возникает.

Есть ли требования к схеме?

Для log shipping нет требований к схеме, тогда как во всех формах репликации транзакций требуется первичный ключ на таблицах.

Есть ли возможность выбрать отдельную таблицу?

C помощью Log shipping переносятся все таблицы, хранимые процедуры, триггеры и т.д. существующие на издателе. Репликация же позволяет выбрать отдельные таблицы.

Будет ли доступна база на подписчике/резервном сервере?

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

Передаются ли системные данные?

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

Можно ли использовать подписчика/резервный сервер для задач отчётности?

Log shipping обычно не позволяет использовать резервный сервер для отчетности, т.к. log shipping требует эксклюзивной блокировки на базе данных при восстановлении журнала, в процессе восстановления пользователи будут немедленно отключены, либо log shipping закончится с ошибкой.
Репликация позволяет запускать запросы, при этом не требуется много ресурсов и такие запросы выполняются очень быстро.

Заключение

Автор надеется на то, что эта статья поможет Вам сделать правильный выбор.
Хотя это немного упрощенный вариант, автор рекомендует использовать log shipping, затем репликацию транзакций с отложенным обновлением подписчиков. Этот порядок изменяется, если есть необходимость вернуться обратно на промышленный сервер, как только все восстановлено (в этом случае можно просто запустить queue reader agent'а) или если есть необходимость в том чтобы резервный сервер функционировал дополнительно как сервер для сбора отчетности.

[В начало]