Технология Клиент-Сервер 2010'1

Home

Поиск

Издания

Контакты

k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Масштабирование баз данных распространителя (distribution database)

Автор: Дэвид Пуле (David Poole)

Опубликовано: 08.07.2010
Версия текста: 1.1

Базовая топология репликации

Множественные БД распространителя

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

Настраиваем репликацию для использования новой БД распространителя

Если у вас уже имеются публикации
Настройка из скрипта

Настройка из Management Studio

Заключительные мысли

Репликация в SQL Server – это зрелые и надежное средство для копирования данных из одной БД в другую. На сегодня это еще и высокопроизводительное решение.

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

ПО умолчанию сервер, выступающий в роли распространителя, содержит одну БД с названием "distribution", которую далее мы будем называть БД распространителя. По мере роста числа издателей и публикаций мы сталкиваемся с фактом, что эта единственная БД распространителя пытается обработать все транзакции.

К счастью, мы можем установить на сервере- распространителе дополнительные БД распространителя и присвоить каждому распространителю собственную БД.

Базовая топология репликации

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

Издатели поставляют данные распространителю.
Распространитель предоставляет данные подписчикам.

Публикация может включать следующие элементы в любой комбинации:

Таблицы.
Представления.
Индексированные представления.
Пользовательские функции.
Хранимые процедуры.

Можно иметь одну или несколько публикаций из любой БД, и БД на стороне подписчика может иметь одну или несколько подписок.

Эта конфигурация показана на следующей диаграмме:

Рисунок 1.

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

Множественные БД распространителя

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

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

К счастью, на сервере, выступающем в роли распространителя, может быть несколько БД распространителя, как показано на следующей диаграмме:

Рисунок 2.

Копия SQL Server, выступающая в роли издателя, может принадлежать только одному распространителю и одной БД распространителя. В приведенной выше диаграмме не может быть так, что Publish_01 использует Distribution_A, а Publish_02 использует Distribution_B, если Publish_01 и Publish_02 не работают на разных экземплярах SQL Server на одной машине.

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

Это просто сделать с помощью Management Studio или скриптов.

Следующий фрагмент кода добавляет новую базу данных распространителя с названием "QA_Distribution".

USE master
GO
exec sp_adddistributiondb
  @database = N'QA_Distribution',
  @data_folder = 
    N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data',
  @log_folder = 
    N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data',
  @data_file_size = 5,
  @log_file_size = 5,
  @min_distretention = 0,
  @max_distretention = 24,
  @history_retention = 24,
  @security_mode = 1
GO

В таблице 1 приведены параметры хранимой процедуры sp_adddistributiondb.

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

USE [QA_Distribution]
GO
IF NOT EXISTS (
  SELECT * FROM sysobjects WHERE name = 'UIProperties' AND type = 'U ')
    CREATE TABLE UIProperties(id INT)

IF EXISTS (
  SELECT * 
    FROM ::fn_listextendedproperty(
      'SnapshotFolder', 'user','dbo', 'table', 'UIProperties', null, null))
  EXEC sp_updateextendedproperty
   N'SnapshotFolder', 
   N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\ReplData',
        'user', 
        dbo, 
        'table',
        'UIProperties'
ELSE
  EXEC sp_addextendedproperty 
   N'SnapshotFolder', 
   N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\ReplData', 
   'user', 
   dbo, 
   'table',
   'UIProperties'
GO

Этот отрывок кода создает пользовательскую таблицу UIProperties и добавляет в нее расширенное свойство "SnapshotFolder", которое содержит путь к BCP-файлам snapshot-ов.

Таблица 1.

Параметр	Комментарий
@data_folder @Log_folder	Если вы достигли точки, где вам нужны отдельные БД распространителя, то в идеале вы должны стремиться хранить БД распространителя и журнальные файлы на быстрых дисках.
@data_file_size @log_file_size	Размер выражается в MB. В идеале размеры файлов должны быть достаточно велики, чтобы не потребовалось их автоматическое увеличение.
@max_distretention	В Books Online сказано, что это максимальный срок хранения транзакций перед удалением (в часах). Если подписчик не получает транзакций от распространителя, и существуют транзакции старше этого срока, то подписку следует пометить как не активную. По умолчанию используется значение 72 часа, но вы должны сами решить, может ли реально ваш дистрибьютор удерживать транзакции в течение 72 часов. Если у вашей компании есть поддержка на условиях 24/7, и вы можете исправить проблемы с репликацией в течение 4 часов, снизьте это значение часов до 8. Почему часов до 8? Старое правило администраторов – прикиньте значение, умножьте на два и добавьте еще немного.
@history_retention	Это значение показывает, как долго вы хотите сохранять историю репликации. Опять же, если вы работаете на условиях 24/7, используемые по умолчанию 48 часов – это, возможно, слишком много.

В Management Studio это делается следующим образом:

Подключитесь к распространителю
Щелкните правой кнопкой по репликации и выберите "Distributor Properties" (рисунок 3).

Рисунок 3.

В диалоге Distributor Properties выберите "New" (рисунок 4).

Рисунок 4.

Заполните появляющийся диалог (рисунок 5).

Нужно подчеркнуть, что Management Studio не позволяет в этом диалоге задать размеры файлов данных и лога, так что, как уже говорилось по поводу параметров хранимой процедуры sp_adddistributiondb, вам надо отдельно задать эти размеры, чтобы эти файлы не потребовали автоувеличения в дальнейшем.

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

Настраиваем репликацию для использования новой БД распространителя

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

Рисунок 5.

Если у вас уже имеются публикации

Это немного неудобно. Вам придется отменить ВСЕ публикации и подписки, а затем сбросить подписки и публикации, прежде чем двигаться дальше.

Это необходимо, так как изменение БД распространителя влияет на всего распространителя.

Настройка из скрипта

Приведенного ниже кода достаточно чтобы назначить БД распространителя издателю:

exec sp_adddistpublisher
  @publisher = N'DEVELOPMENT',
  @distribution_db = N'QA_Distribution',
  -- Используйте доверительную безопасность, чтобы позволить распространителю
  -- общаться с издателем. 
  @security_mode = 1, 
  @working_directory = 
   N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\ReplData',
-- устаревшее, только для обратной совместимости
  @trusted = N'false', 
  -- 0 = SQL Server, 1 = другое (возможно, ORACLE)
  @thirdparty_flag = 0, 
  @publisher_type = N'MSSQLSERVER'

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

Настройка из Management Studio

Это, вообще-то, головная боль, и хороший пример места, где Management Studio можно было бы и улучшить. Выполните следующее:

Подключитесь к вашему распространителю.
Щелкните правой кнопкой по репликации и выберите "Distributor Properties".
В левой панели выберите "Publishers", чтобы вызвать диалоговое окно, аналогичное показанному на рисунке 6.

Рисунок 6.

Снимите флажок с издателя, для которого вы хотите переопределить БД распространителя.
Выберите ОК, чтобы закрыть диалоговое окно. Вы получите окно с предупреждением о том, что вы пытаетесь отключить данного издателя, и что все публикации и подписки будут удалены. Именно из-за этого нужно записать все свои подписки и публикации, прежде чем делать это! Несмотря на предупреждение о том, что все публикации и подписки будут удалены, я обнаружил, что Management Studio оставляет за собой не удаленные подписки, и мне пришлось удалять публикации и подписки вручную.
Повторите первые 3 шага. На этот раз ваш издатель не будет показан, поэтому нажмите кнопку "Add".
Подключитесь к вашему издателю, и вы снова получите диалоговое окно "Publishers", только на этот раз вы сможете выбрать БД распространителя из выпадающего списка (рисунок 7).

Рисунок 7.

После нажатия ОК издатель будет настроен на использование указанной БД распространителя.

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

Заключительные мысли

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

Благодаря наличию нескольких БД распространителя на самом деле можно получить большие преимущества просто потому, что транзакции от издателя "x" не будут больше тормозить БД распространителя издателя "y".

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

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

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