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

Изменения: 17 июля 2006 г.

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

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

ms151799.note(ru-ru,SQL.90).gifПримечание.
После перехода на зеркальную базу данных в результате сбоя основной базы данных зеркальная база данных становится основной. В этом разделе термины «основная» и «зеркальная» всегда относятся к исходной основной и зеркальной базе данных соответственно.

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

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

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

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

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

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

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

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

  1. Настройте издатель.

    1. Рекомендуется использовать удаленный распространитель. Дополнительные сведения о настройке распространения см. в разделе Настройка распространителя.

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

      exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true
      exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true
      

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

  2. Настройте зеркальное отображение базы данных. Дополнительные сведения см. в разделах Как настроить сеанс зеркального отображения базы данных (среда SQL Server Management Studio) и Настройка зеркального отображения базы данных.

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

    • установите значение параметра @publisher равным сетевому имени зеркала;
    • установите значение параметра @working_directory равным имени папки моментальных снимков, используемой основной базой данных.
  4. Укажите имя зеркала для параметра агента –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>'
    
  5. Добавьте основную и зеркальную базы данных в монитор репликации. Дополнительные сведения см. в разделе Как добавлять и удалять издателей в мониторе репликации (монитор репликации).

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

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

  • Администрирование и контроль должны выполняться на активном сервере. В среде SQL Server Management Studio публикации находятся в папке Локальные публикации только на активном сервере. Например, если в результате сбоя выполнен переход на зеркало, публикации отображаются на зеркале и больше не отображаются в основной базе данных. Если база данных переходит в результате сбоя на зеркало, возможно, понадобится вручную обновить среду Management Studio и монитор репликации, чтобы в них отображалось произошедшее изменение.
  • Монитор репликации отображает узлы издателя в дереве объектов как для основного, так и для зеркального сервера. Если активным является основной сервер, сведения о публикации отображаются в мониторе репликации только на главном узле.
    Если активным является зеркальный сервер:
    • если возникла ошибка агента, эта ошибка показывается только в основном узле и не отображается в зеркальном узле;
    • если основной сервер недоступен, то в основном и зеркальном узлах отображаются идентичные списки публикаций. Контроль должен выполняться только для публикаций на зеркальном узле.
  • Если для администрирования репликации на зеркале используются хранимые процедуры или объекты RMO, то для случаев, когда указывается имя издателя, необходимо указать имя экземпляра, на котором база данных активирована для репликации. Чтобы определить соответствующее имя, воспользуйтесь функцией publishingservername.
    Когда база данных публикации зеркально отображается, метаданные репликации, хранимые в зеркальной базе данных, идентичны метаданным, хранимым в основной базе данных. Поэтому для баз данных публикации, активированных для репликации на основном сервере, имя экземпляра издателя, хранимое в системных таблицах на зеркале, является именем основного сервера, а не именем зеркала. Если в результате сбоя база данных публикации переходит на зеркальный сервер, это повлияет на настройку и обслуживание репликации. Например, если после сбоя и перехода на резервный ресурс репликация настраивается с помощью хранимых процедур на зеркале и требуется добавить подписку по запросу в базу данных публикации, которая была активирована в основной базе данных, необходимо указать имя основной, а не зеркальной базы данных в параметре @publisher хранимой процедуры sp_addpullsubscription или sp_addmergepullsubscription.
    Если база данных публикации активирована на зеркале после перехода на зеркало в результате сбоя, имя экземпляра издателя, хранимое в системных таблицах, должно быть именем зеркала. В этом случае будет использоваться имя зеркала для параметра @publisher.
    ms151799.note(ru-ru,SQL.90).gifПримечание.
    В некоторых ситуациях, например sp_addpublication, параметр @publisher поддерживается только для издателей, отличных от SQL Server. В этих случаях параметр не влияет на зеркальное отображение базы данных SQL Server.
  • Для синхронизации подписки в среде Management Studio после перехода на резервный ресурс в результате сбоя необходимо синхронизировать подписки по запросу от подписчика и синхронизировать принудительные подписки от активного издателя.

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

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

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

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

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

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

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

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

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

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

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

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

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

Журнал изменений

Версия Журнал

17 июля 2006 г.

Измененное содержимое
  • Дано разъяснение о порядке, в котором выполняются процедуры sp_adddistpublisher и sp_adddistributor при настройке распространения для зеркального сервера.

См. также

Основные понятия

Репликация и доставка журналов

Другие ресурсы

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

Справка и поддержка

Получение помощи по SQL Server 2005