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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Баз данных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

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

См. также:

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