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

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

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

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

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

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

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

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

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

• Снимок применяется агентом распределения или агентом слияния. Вы можете просмотреть состояние применения моментального снимка на странице Агент распространителя или Агент слияния в Мониторе репликации. См. дополнительные сведения о просмотре сведений и выполнении задач с помощью монитора репликации.

Если агент распространения или агент слияния запускаются одновременно с агентом моментальных снимков, это не вызовет ошибку. Однако необходимо помнить о следующем:

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

• Если агент распространителя или агент слияния настроен на запуск по расписанию или по требованию, и при запуске агента моментальный снимок недоступен, то агент завершит работу, выдав сообщение о том, что моментальный снимок еще не доступен. Чтобы применить моментальный снимок, нужно снова запустить агента после завершения работы агента моментального снимка. Дополнительные сведения о запуске агентов см. в статьях о синхронизации Push-подписки, синхронизации Pull-подписки и концепциях исполняемых файлов агентов репликации.

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

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

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

• Репликация слиянием добавляет к каждой таблице столбец rowguid , если только таблица уже не содержит столбец данных типа uniqueidentifier с установленным свойством ROWGUIDCOL (в этом случае используется этот столбец). Если таблица удалена из публикации, столбец rowguid удаляется; если существующий столбец был использован для слежения, столбец не удаляется.

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

• Фильтр не должен включать столбец rowguidcol , который используется в процессе репликации для идентификации строк. По умолчанию при настройке репликации слиянием этот столбец добавляется и называется rowguid.

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

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

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

• Параметр NOT FOR REPLICATION по умолчанию задается для ограничений внешнего ключа и проверочных ограничений. Ограничения используются для пользовательских операций, но не для операций агентов.

Сведения об установке параметров схемы, которые управляют репликацией ограничений, см. в разделе Specify Schema Options.

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

Да, но с некоторыми ограничениями. Дополнительные сведения см. в разделе "Публикация таблиц в нескольких публикациях" статьи Публикация данных и объектов базы данных.

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

При наличии нескольких публикаций на распространителе можно настроить несколько баз данных распространителя для гарантии того, что данные, проходящие через каждую базу данных распространителя, идут из одной публикации. Используйте диалоговое окно "Свойства распространителя" или sp_adddistributiondb (Transact-SQL) для добавления базы данных распространителя. Дополнительные сведения о доступе к этому диалоговому окну см. в статье View and Modify Distributor and Publisher Properties (Просмотр и изменение свойств издателя и распространителя).

Эта информация доступна через SQL Server Management Studio и ряд хранимых процедур репликации. Дополнительные сведения см. в статье Distributor and Publisher Information Script.

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

Репликация данных через Интернет:

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

• Параметр веб-синхронизации для репликации слиянием. Дополнительные сведения см. в статье Web Synchronization for Merge Replication.

Все типы репликации Microsoft SQL Server могут реплицировать данные по VPN, но при использовании репликации слиянием следует учитывать веб-синхронизацию.

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

Да, репликация работает по соединениям с малой полосой пропускания. Для соединений по TCP/IP-протоколу используется сжатие, предоставляемое протоколом, но дополнительное сжатие отсутствует. Для соединений веб-синхронизации по HTTPS-протоколу используется сжатие, предоставляемое протоколом, и дополнительное сжатие XML-файлов, используемых для репликации изменений.

Нет, репликация работает только при использовании фактического имени сервера. Начиная с SQL Server Management Studio (SSMS) 18.0, репликацию можно настроить с помощью фактического имени сервера и номера порта.

№ Вы можете создать пакет SSIS для передачи имен входа и паролей от издателя любому числу подписчиков.

Начиная с Microsoft SQL Server 2005 (9.x), схема имеет два значения:

• Определение объекта, например инструкция CREATE TABLE. По умолчанию репликация копирует определения всех реплицируемых объектов на подписчика.

• Пространство имен, в котором создается объект: <База данных>.<Схема>.<Объект>. Схемы определяются с помощью инструкции CREATE SCHEMA.

• Репликации свойственно следующее поведение по умолчанию в мастере создания публикаций, касающееся схем и принадлежности объектов:

• Для статей в публикациях слиянием с уровнем совместимости 90 или выше, публикациях моментальных снимков и публикациях транзакций: по умолчанию владелец объекта на подписчике идентичен владельцу соответствующего объекта на издателе. Если у подписчика отсутствуют схемы, которые владеют объектами, они создаются автоматически.

• Для статей в публикациях слияния с уровнем совместимости ниже 90: по умолчанию владелец не указывается и в процессе создания объекта на подписчике назначается как dbo.

• Для статей в публикациях Oracle: по умолчанию владельцем назначается dbo.

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

Владельца объекта можно изменить с помощью диалогового окна Свойства статьи — <статья> и следующих хранимых процедур: sp_addarticle, sp_addmergearticle, sp_changearticle и sp_changemergearticle. Дополнительные сведения см. в статье Просмотр и изменение свойств публикации, Определение статьи и Просмотр и изменение свойств статьи.

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

• Непосредственно выполнить инструкции GRANT в базе данных подписки.

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

• Хранимая процедура sp_addscriptexec используется для запуска инструкций.

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

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

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

  • Выполните хранимую процедуру sp_changearticle или sp_changemergearticle. Задайте значение 'pre_creation_cmd' (хранимая процедура sp_changearticle) или 'pre_creation_command' (хранимая процедура sp_changemergearticle) для параметра @property и значение 'none', 'delete' или 'truncate' для параметра @value.

  • "В диалоговом окне Свойства статьи - <Статья> в разделе Целевой объект выберите значение «Сохранить существующий объект без изменений», «Удалить данные». Если в статье есть фильтр строк, удалите только данные, соответствующие фильтру, или «Трунцировать все данные в существующем объекте» для параметра «Действие, если имя используется». Дополнительные сведения о доступе к этому диалоговому окну см. в статье Просмотр и изменение свойств публикации.

TRUNCATE TABLE — это инструкция на языке DDL, которая не записывает в журнал отдельные операции удаления строк и не вызывает срабатывание триггеров DML. Она недопустима, так как репликация не может отследить вносимые ею изменения: репликация транзакций отслеживает изменения посредством журнала транзакций, а репликация слиянием — посредством триггеров DML в публикуемых таблицах.

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

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

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

Кроме этого, если в базе данных публикации или распространителя установлен параметр «sync with backup», то журнал транзакций не усекается до тех пор, пока не будет осуществлено резервное копирование всех транзакций. Если журнал транзакций становится слишком большим и этот параметр установлен, то необходимо рассмотреть сокращение интервалов резервного копирования журнала транзакций. Дополнительные сведения о резервном копировании и восстановлении баз данных, которые участвуют в транзакционной репликации, см. в статье Strategies for Backing Up and Restoring Snapshot and Transactional Replication (Стратегии резервного копирования и восстановления моментальных снимков и транзакционной репликации).

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

Индексы можно добавлять на издателе или подписчиках без особых предосторожностей в отношении репликации (не следует забывать, что индексы влияют на производительность). CREATE INDEX и ALTER INDEX не реплицируются, поэтому, например, при добавлении или изменении индекса у издателя необходимо также создать или изменить его у подписчика, чтобы он отразился и там.

В версиях SQL Server до SQL Server 2005 (9.x) перемещение или переименование файлов базы данных требовали отсоединения и повторного присоединения базы данных. Поскольку реплицируемую базу данных отсоединить нельзя, необходимо было вначале удалить репликацию из этих баз данных. Начиная с SQL Server 2005 (9.x), вы можете перемещать или переименовать файлы без отключения и повторного присоединения базы данных без влияния на репликацию. Дополнительные сведения о перемещении и переименовании файлов см. в статье ALTER DATABASE (Transact-SQL).

Сначала удалите статью из публикации с помощью sp_droparticle, sp_dropmergearticle или диалогового окна "Свойства публикации - Публикация", а затем удалите ее из базы данных с помощью DROP <Object>. После того как подписки добавлены, невозможно удалить элементы из моментального снимка или транзакционных публикаций; сначала нужно удалить подписки. Дополнительные сведения см. в статье Добавление и удаление статей в существующих публикациях.

SQL Server поддерживает широкий спектр изменений схемы в опубликованных объектах, включая добавление и удаление столбцов. Например, выполните ALTER TABLE … DROP COLUMN на издателе, и эта инструкция будет реплицирована на подписчиках, а затем выполнена для удаления столбца. Подписчики, работающие с версиями SQL Server до SQL Server 2005 (9.x), поддерживают добавление и удаление столбцов с помощью хранимых процедур sp_repladdcolumn и sp_repldropcolumn. Дополнительные сведения см. в статье Внесение изменений в схемы баз данных публикации.

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

Для добавления таблицы (или другого объекта) к базе данных публикации или подписки не обязательно останавливать операции в ней. Добавьте таблицу в публикацию с помощью диалогового окна Свойства публикации - <Публикация> или хранимых процедур sp_addarticle и sp_addmergearticle. Дополнительные сведения см. в статье Добавление и удаление статей в существующих публикациях.

Удалите таблицу из публикации с помощью sp_droparticle, sp_dropmergearticle или в диалоговом окне "Свойства публикации - Публикация". После добавления подписок невозможно удалить статьи из публикаций с моментальными снимками или транзакций; сначала следует удалить подписки. Дополнительные сведения см. в статье Добавление и удаление статей в существующих публикациях.

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

Существует несколько видов изменений статей и публикаций, которые приводят к тому, что моментальные снимки становятся недействительными, следовательно, требуется создание нового моментального снимка. Дополнительные сведения см. в статье Изменение свойств публикации и статьи.

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

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

Для репликации слиянием используйте хранимую процедуру sp_showpendingchanges. Дополнительные сведения см. в разделе sp_showpendingchanges (Transact-SQL).

Используйте хранимую процедуру sp_replmonitorsubscriptionpendingcmds или вкладку Нераспределенные команды в мониторе репликации. Отображение хранимой процедуры и вкладки:

• Количество команд в базе данных распространителя, которые не были доставлены выбранному подписчику. Команда состоит из одной инструкции языка обработки данных (DML) или одной инструкции языка определения данных (DDL) языка Transact-SQL.

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

Дополнительные сведения см. в разделе sp_replmonitorsubscriptionpendingcmds (Transact-SQL) и Просмотр сведений и выполнение задач с помощью Монитора репликации.

Да. Дополнительные сведения см. в разделе "Доставка журналов и репликация" (SQL Server) и зеркальное отображение базы данных и репликация (SQL Server).

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

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

См. также

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