Поделиться через

Рекомендации по администрированию репликации

  • Статья

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

Рекомендации удобно разбить на две группы:

  • Приводимые ниже сведения охватывают рекомендации, которые следует использовать для всех топологий репликации:
    • Разработайте и проверьте стратегию резервного копирования и восстановления.
    • Создайте сценарий для топологии репликации.
    • Создайте пороговые значения и предупреждения.
    • Ведите наблюдение за топологией репликации.
    • Установите исходные уровни производительности и настройте репликацию при необходимости.
  • Приводимые ниже сведения охватывают рекомендации, которые следует рассмотреть, но не обязательно применять в топологии:
    • Периодически проверяйте данные.
    • Настройте параметры агента с помощью профилей.
    • Настройте сроки хранения публикации и распространителя.
    • Разберитесь в том, как следует изменить свойства статьи и публикации при изменении требований приложения.
    • Разберитесь в том, как следует выполнить изменения схемы при изменении требований приложения.

Создание и тестирование резервной копии и стратегия восстановления

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

  • Базы данных публикации
  • Базы данных распространителя
  • Баз данных подписки
  • Баз данных msdb и master на издателе, распространителе и на всех подписчиках

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

Создание сценария для топологии репликации

Все компоненты репликации в топологии должны использоваться в сценарии как часть плана аварийного восстановления. Также можно использовать сценарии для автоматизации повторяющихся задач. Сценарий содержит системные хранимые процедуры Transact-SQL, необходимые для реализации содержащихся в сценарии компонентов репликации, например публикации или подписки. Сценарии могут быть созданы с помощью мастера (например мастера создания публикаций) или в Microsoft SQL Server Management Studio после создания компонента. Сценарий можно просмотреть, изменить и запустить с помощью SQL Server Management Studio или sqlcmd. Сценарии могут сохраняться с файлами резервных копий для использования в случае, когда необходимо перенастроить топологию репликации. Дополнительные сведения см. в разделе Как создавать сценарии репликации объектов (среда SQL Server Management Studio).

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

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

Перед настройкой репликации рекомендуется ознакомиться с факторами, влияющими на производительность репликации:

  • серверное и сетевое аппаратное обеспечение;
  • структура базы данных;
  • конфигурация распространителя;
  • структура и параметры публикации;
  • структура фильтра и его использование;
  • параметры подписок;
  • параметры моментального снимка;
  • параметры агентов;
  • обслуживание.

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

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

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

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

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

Создание пороговых значений и предупреждений

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

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

Наблюдение за топологией репликации

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

Периодическая проверка данных

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

Рекомендуется проводить проверку данных согласно расписанию резервного копирования базы данных публикации. Например, если полное резервное копирование базы данных публикации проводится раз в неделю, то проверка данных могла бы выполняться раз в неделю после завершения резервного копирования. Дополнительные сведения см. в разделе Проверка реплицированных данных.

Использование профилей агента для изменения его параметров в случае необходимости

Профили агента обеспечивают удобный способ установки параметров агента репликации. Параметры могут также указываться в командной строке агента, но обычно целесообразнее использовать предопределенный профиль агента или создать новый профиль, если надо изменить значение какого-либо параметра. Например, если используется репликация слиянием и подписчик переходит с широкополосного подключения на коммутируемое подключение, рассмотрите возможность использования профиля slow link агента слияния. Этот профиль содержит ряд параметров, которые лучше подходят для менее скоростного канала связи. Дополнительные сведения см. в разделе Профили агента репликации.

Настройка при необходимости сроков хранения публикации и распространителя

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

Порядок изменения публикаций в случае изменения требований приложения

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

Внесение изменений схемы в случае изменения требований приложения

Во многих случаях изменения схемы требуются уже после запуска приложения. В топологии репликации эти изменения часто должны быть распространены на все подписчики. Репликация поддерживает широкий диапазон изменений схем для опубликованных объектов. Когда выполняется любое из следующих изменений схемы соответствующего опубликованного объекта на издателе Microsoft SQL Server, это изменение распространяется по умолчанию на все подписчики SQL Server:

  • ALTER TABLE
  • ALTER VIEW
  • ALTER PROCEDURE
  • ALTER FUNCTION
  • ALTER TRIGGER

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

См. также

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

Управление репликацией

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

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