Best Practices for Replication Administration

  • Статья

Применимо к:Управляемому экземпляру SQL Server Azure

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

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

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

    • Разработайте и проверьте стратегию резервного копирования и восстановления.

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

    • Создайте пороговые значения и предупреждения.

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

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

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

    • Периодически проверяйте данные.

    • Настройте параметры агента с помощью профилей.

    • Настройте сроки хранения публикации и распространителя.

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

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

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

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

  • Базы данных публикации

  • Базы данных распространителя

  • Баз данных подписки

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

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

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

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

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

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

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

  • серверное и сетевое аппаратное обеспечение;

  • Проектирование базы данных

  • конфигурация распространителя;

  • структура и параметры публикации;

  • структура фильтра и его использование;

  • Параметры подписки

  • Параметры моментального снимка

  • Параметры агента

  • Обслуживание

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

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

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

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

  • Длительность синхронизации: время, затрачиваемое на выполнение заданной синхронизации.

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

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

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

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

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

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

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

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

  • Монитор репликации является самым важным инструментом наблюдения за репликацией, позволяющим отслеживать исправность топологии репликации. Дополнительные сведения см. в разделе Monitoring Replication.

  • Объекты управления репликацией Transact-SQL и репликации (RMO) предоставляют интерфейсы для мониторинга репликации. Дополнительные сведения см. в разделе Monitoring Replication.

  • Системный монитор также может быть полезным для наблюдения за производительностью репликации. Дополнительные сведения см. в статье Monitoring Replication with System Monitor.

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

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

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

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

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

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

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

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

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

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

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

  • ALTER TABLE

  • ALTER VIEW

  • ALTER PROCEDURE

  • ALTER FUNCTION

  • ALTER TRIGGER

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

См. также

Вопросы и ответы об администрировании репликации