12.5. Подготовка к настройке репликации

Выбор типа репликации в SQL Server 2005, выбор роли для серверов, параметр NOT FOR REPLICATION

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

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

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

q      загрузку сервера. Очень часто издатель — это самый загруженный сервер, поэтому лучше сделать распространителем другой компьютер;

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

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

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

В SQL Server можно сделать так, что при репликации будут игнорировать некоторые объекты базы данных издателя, если использовать для этих объектов параметр NOT FOR REPLICATION. Этот параметр можно применить:

q      для внешних ключей (foreign key). При вставке или изменении данных средствами репликации в таблицах подписчика это ограничение целостности использовать не будет;

q      для условий на значение (объектов check);

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

q      для столбцов счетчика (identity columns). При вставке новых записей средствами репликации такие столбцы будут восприниматься как обычные (например, с целочисленным типом данных). Автоматическое приращение значений для таких столбцов производиться не будет.

Параметр NOT FOR REPLICATION можно определить как при настройке репликации, так и при обычном создании объектов с помощью скриптов Transact-SQL.

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

Проблемы могут возникнуть и со столбцами BLOB — типами данных text, ntext и image. Репликация слиянием требует, чтобы после команды WRITETEXT или UPDATETEXT в той же транзакции обязательно присутствовала команда UPDATE (иначе не сработает триггер, и информация об изменениях не будет передана подписчикам). Репликация транзакций при выполнении операций с такими значениями обязательно требует помещения команд WRITETEXT или UPDATETEXT в явно объявленные транзакции. Кроме того, для команд WRITETEXT и UPDATETEXT должен обязательно использоваться параметр WITH LOG, иначе информация о таких операциях не будет занесена в журнал транзакции и, соответственно, не будет реплицирована.

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

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

Получить учебные материалы по этому курсу