Статья
04/01/2012

Репликация и зеркальное отображение базы данных

Зеркальное отображение базы данных может быть использовано для повышения доступности определенных баз данных репликации. Возможность совместно использовать репликацию транзакций с зеркальным отображением базы данных зависит от того, какая это база данных репликации. Одноранговая репликация не поддерживается в сочетании с зеркальным отображением баз данных. Дополнительные сведения о зеркальном отображении базы данных см. в разделе Администрирование зеркального отображения базы данных.

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

База данных репликации	Поддерживается для использования с зеркальным отображением базы данных
Публикация	Да. Поддерживается как для репликации слиянием, так и для репликации транзакций с автоматическим переходом на другой ресурс. Агенты репликации, которые подключены к базе данных публикации, могут автоматически переходить на зеркальную базу данных публикации. В случае сбоя агенты, подключенные к базе данных публикации, будут автоматически переподключены к новой основной базе данных.
Распространение	Нет. Зеркальное отображение базы данных распространителя не поддерживается. База данных распространителя — это база, где хранится конфигурация репликации, а метаданные этой конфигурации тесно связаны с именем сервера, на котором настроен распространитель. Имя сервера изменится при отработке отказа зеркальной базы данных, а данные конфигурации, хранящиеся в базе данных распространителя, будут указывать на старый сервер базы данных распространителя.
Подписка	Да. Поддерживается, начиная с SQL Server 2008, для репликации транзакций с конфигурацией и переходом на другой ресурс вручную. Агенты репликации, которые подключаются к базе данных подписки, не поддерживают зеркальное отображение. При отказе основной базы данных подписки отработка отказа базы данных-получателя требует выполнения некоторых шагов вручную, которые дадут возможность восстановить поток репликации. Дополнительные сведения см. в разделе Репликация SQL Server. Обеспечение высокого уровня доступности с помощью зеркального отображения базы данных (техническая статья SQL Server).

Публикация

Да.

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

Распространение

Нет.

Зеркальное отображение базы данных распространителя не поддерживается. База данных распространителя — это база, где хранится конфигурация репликации, а метаданные этой конфигурации тесно связаны с именем сервера, на котором настроен распространитель. Имя сервера изменится при отработке отказа зеркальной базы данных, а данные конфигурации, хранящиеся в базе данных распространителя, будут указывать на старый сервер базы данных распространителя.

Да.

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

Сведения о восстановлении базы данных распространителя и базы данных подписки без перенастройки репликации см. в разделе Резервное копирование и восстановление из копий реплицируемых баз данных.

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

После перехода на зеркальную базу данных в результате отработки отказа основной базы данных зеркальная база данных становится основной. В этом разделе термины «основная» и «зеркальная» всегда относятся к исходной основной и зеркальной базе данных соответственно.

Требования и дополнительные соображения по использованию репликации с зеркальным отображением базы данных

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

Основная и зеркальная базы данных должны совместно использовать распространитель. Рекомендуется, чтобы это был удаленный распространитель, который обеспечивает большую устойчивость к отказам в ситуации, когда на издателе при сбое происходит незапланированная отработка отказа.
Издатель и распространитель должны использовать Microsoft SQL Server 2005 или более позднюю версию. Подписчики могут использовать любую версию, однако в версиях, предшествующих SQL Server 2005, подписки по запросу для репликации слиянием не поддерживают отработку отказа. В этом случае агент выполняется на подписчике, а агентам предыдущих версий неизвестно о существовании зеркальной базы данных. Репликация на такие подписчики возобновляется, если происходит обратный переход с зеркальной базы данных на основную базу данных.
Репликация поддерживает зеркальное отображение базы данных публикации для репликации слиянием и репликации транзакций с подписчиками, доступными только для чтения, или с подписчиками, обновляемыми посредством очередей. Подписчики с немедленным обновлением, издатели Oracle, издатели в одноранговой топологии, а также переиздающие подписчики не поддерживаются.
Метаданные и объекты, которые существуют за пределами базы данных, не копируются на зеркало. Это касается имен входа, заданий, связанных серверов и так далее. Если в зеркальной базе данных нужны метаданные и объекты, их необходимо скопировать вручную. Дополнительные сведения см. в разделе Управление именами входа и заданиями после переключения ролей.

Настройка репликации с зеркальным отображением базы данных

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

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

Шаги 1 и 2 могут быть выполнены в обратном порядке.

Настройка зеркального отображения базы данных для базы данных публикации

Настройте издатель.
1. Рекомендуется использовать удаленный распространитель. Дополнительные сведения о настройке распространения см. в разделе Настройка распространителя.
2. Базу данных можно активировать для использования публикаций моментальных снимков, публикаций транзакций или публикаций слиянием. Для зеркальных баз данных, которые будут содержать более одного типа публикаций, базу данных при помощи процедуры sp_replicationdboption следует активировать для обоих типов публикаций на том же узле. Например, можно было бы выполнить следующие вызовы хранимых процедур в основной базе данных:
```
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true
```
  Дополнительные сведения о создании публикаций см. в разделе Публикация данных и объектов базы данных.
Настройте зеркальное отображение базы данных. Дополнительные сведения см. в разделах Как настроить сеанс зеркального отображения базы данных (среда SQL Server Management Studio) и Настройка зеркального отображения базы данных.
Настройте распространение для зеркальной базы данных. Укажите имя зеркальной базы данных в качестве имени издателя и укажите те же самые распространитель и папку моментальных снимков, которые используются основной базой данных. Например, если проводится настройка репликации с помощью хранимых процедур, выполните sp_adddistpublisher на распространителе, а затем sp_adddistributor на зеркальном сервере. Для sp_adddistpublisher выполните следующее.
- установите значение параметра @publisher равным сетевому имени зеркала;
- установите значение параметра @working_directory равным имени папки моментальных снимков, используемой основной базой данных.
Укажите имя зеркала в параметре агента –PublisherFailoverPartner. Этот параметр требуется следующим агентам для определения зеркала после отработки отказа:
- агенту моментальных снимков (для всех публикаций);
- агенту чтения журнала (для всех публикаций транзакций);
- агенту чтения очереди (для публикаций транзакций, которые поддерживают подписки, обновляемые посредством очередей);
- агенту слияния (для подписок на публикацию слиянием);
- прослушивателю репликации SQL Server (replisapi.dll: для подписок на публикацию слиянием, синхронизируемых с помощью веб-синхронизации);
- элементу управления ActiveX слияния SQL (для подписок на публикацию слиянием, синхронизируемых с помощью этого элемента управления).
Агент распространителя и элемент управления ActiveX распространения не имеют этого параметра, потому что они не подключаются к издателю.

Изменения параметров агента вступают в действие при следующем запуске агента. Если агент выполняется в непрерывном режиме, следует остановить и перезапустить агент. Параметры могут быть заданы в профилях агента или из командной строки. Дополнительные сведения см. в разделах:
Рекомендуется добавить параметр –PublisherFailoverPartner в профиль агента, а затем указать в профиле имя зеркала. Например, если настраивается репликация с помощью хранимых процедур:
```
-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.
-- Select the profile id of the profile that needs to be updated from the result set.
-- In the agent_type column returned by sp_help_agent_profile: 
-- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.

exec sp_help_agent_profile

-- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).
-- Execute sp_add_agent_parameter in the context of the distribution database.
exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'

-- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).
-- Execute sp_add_agent_parameter in the context of the distribution database.
exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'
```
Добавьте основную и зеркальную базы данных в монитор репликации. Дополнительные сведения см. в разделе Как добавлять и удалять издателей в мониторе репликации (монитор репликации).

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

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

Администрирование и наблюдение должны выполняться на активном сервере. В среде Среда SQL Server Management Studio в папке Локальные публикации находятся публикации только для активного сервера. Например, если в результате отработки отказа выполнен переход на зеркало, публикации будут отображаться на зеркале и больше не будут отображаться в основной базе данных. Если база данных переходит на зеркальный сервер, возможно, понадобится вручную обновить среду Management Studio и монитор репликации, чтобы в них отображалось произошедшее изменение.
Монитор репликации отображает узлы издателя в дереве объектов как для основного, так и для зеркального сервера. Если активным является основной сервер, сведения о публикации отображаются в мониторе репликации только на главном узле.

Если активным является зеркальный сервер:
- если возникла ошибка агента, эта ошибка показывается только в основном узле и не отображается в зеркальном узле;
- если основной сервер недоступен, то в основном и зеркальном узлах отображаются идентичные списки публикаций. Наблюдение должно выполняться только для публикаций на зеркальном узле.

Если для администрирования репликации на зеркале используются хранимые процедуры или объекты RMO, то для случаев, когда указывается имя издателя, необходимо указать имя экземпляра, на котором база данных активирована для репликации. Чтобы определить соответствующее имя, воспользуйтесь функцией publishingservername.

Когда база данных публикации зеркально отображается, метаданные репликации, хранимые в зеркальной базе данных, идентичны метаданным, хранимым в основной базе данных. Поэтому для баз данных публикации, активированных для репликации на основном сервере, имя экземпляра издателя, хранимое в системных таблицах на зеркале, является именем основного сервера, а не именем зеркала. Если в результате сбоя база данных публикации переходит на зеркальный сервер, это повлияет на настройку и обслуживание репликации. Например, если после отработки отказа репликация настраивается с помощью хранимых процедур на зеркале и требуется добавить подписку по запросу в базу данных публикации, которая была активирована в основной базе данных, необходимо указать имя основной, а не зеркальной базы данных в параметре @publisher хранимой процедуры sp_addpullsubscription или sp_addmergepullsubscription.

Если база данных публикации активирована на зеркале после перехода на зеркало в результате отработки отказа, имя экземпляра издателя, хранимое в системных таблицах, должно быть именем зеркала. В этом случае будет использоваться имя зеркала для параметра @publisher.

Примечание
В некоторых случаях, например в процедуре sp_addpublication, параметр @publisher поддерживается только для издателей, не относящихся к SQL Server, и не влияет на зеркальное отображение базы данных SQL Server.

Для синхронизации подписки в среде Management Studio после отработки отказа необходимо синхронизировать подписки по запросу от подписчика и синхронизировать принудительные подписки от активного издателя.

Поведение репликации, когда зеркальное отображение удалено

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

Если зеркальное отображение опубликованной базы данных на основном сервере больше не выполняется, репликация продолжает работать без изменений для исходной основной базы данных.
Если опубликованная база данных в результате сбоя переключается с основной на зеркальную базу данных и если связи зеркального отображения затем отключаются или удаляются, агенты репликации не будут функционировать в зеркальной базе данных. Если основная база данных бесповоротно утеряна, отключите, а затем перенастройте репликацию с зеркалом, указанным в качестве издателя.
Если зеркальное отображение базы данных полностью удаляется, зеркальная база данных находится в состоянии восстановления и должна быть восстановлена, чтобы стать функционирующей. Поведение восстановленной базы данных в отношении репликации зависит от того, задан ли параметр KEEP_REPLICATION. Этот параметр принудительно запускает операцию восстановления, чтобы сохранить настройки репликации при восстановлении опубликованной базы данных на сервер, отличный от того, на котором была создана резервная копия. Используйте параметр KEEP_REPLICATION, только когда недоступна другая база данных публикации. Этот параметр не поддерживается, если другая база данных публикации не повреждена и реплицируется. Дополнительные сведения о параметре KEEP_REPLICATION см. в разделе RESTORE (Transact-SQL).

Поведение агента чтения журнала

В следующей таблице описывается поведение агента чтения журнала для различных режимов зеркального отображения базы данных. Дополнительные сведения о рабочих режимах см. в разделе Настройки Transact-SQL и режимы зеркального отображения базы данных.

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

Режим высокого уровня защиты с автоматической отработкой отказа

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

Режим с высоким уровнем производительности

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

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

Режим высокой безопасности без автоматической отработки отказа

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