Стратегии резервного копирования и восстановления для моментальных снимков и репликации транзакций

  • Статья

Применимо к:SQL Server База данных SQL Azure

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

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

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

Примечание.

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

Резервное копирование баз данных

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

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

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

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

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

Если резервное копирование журналов выполняется регулярно, любые изменения, касающиеся репликации, будут заноситься в резервные копии журнала. Если не выполняется резервное копирование журналов, то необходимо выполнить это резервное копирование при каждом изменении настройки, относящейся к репликации. Дополнительные сведения см. в статье Common Actions Requiring an Updated Backup.

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

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

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

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

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

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

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

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

    Примечание.

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

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

    Процесс не удалось выполнить "sp_repldone/sp_replcounters" на "machinename\instance". (Источник: MSSQL_REPL, номер ошибки: MSSQL_REPL20011) Получение справки: http://help/MSSQL_REPL20011 возможное несогласованное состояние в базе данных распространителя: dist_backup_lsn {nn:nn:nnnn}, dist_last_lsn {nn:nn:nnnn}. Выполните процедуру "sp_repldone NULL, NULL, 0, 0, 1", а затем процедуру sp_replflush. Выполните повторную инициализацию всех подписок на публикацию. (Источник: MSSQLServer, номер ошибки: 18846)

Установка параметра «sync with backup»

Восстановление баз данных, участвующих в репликации

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

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

Publisher

Последовательность шагов по восстановлению предлагается для следующих типов репликации:

  • репликация моментальных снимков;

  • репликация транзакций, доступная только для чтения;

  • репликация транзакций с обновляемыми подписками;

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

Восстановление баз данных msdb и master , о котором также рассказывается в этом разделе, одинаково для всех четырех типов репликации.

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

  1. Восстановите последнюю резервную копию базы данных публикации. Перейдите к шагу 2.

  2. Содержит ли резервная копия базы данных публикации последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. Восстановление завершено.

    Дополнительные сведения об удалении реплика tion см. в разделе sp_removedbреплика tion (Transact-SQL).

База данных публикации: репликация транзакций, доступная только для чтения

  1. Восстановите последнюю резервную копию базы данных публикации. Перейдите к шагу 2.

  2. Был ли перед сбоем включен параметр sync with backup для базы данных публикации? Если да, перейдите к шагу 3, если нет — к шагу 5.

    Если параметр включен, запрос SELECT DATABASEPROPERTYEX('<PublicationDatabaseName>', 'IsSyncWithBackup') возвращает '1'.

  3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 4.

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

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

      Дополнительные сведения о запуске агент распространения см. в статьях "Запуск и остановка агента репликации" (SQL Server Management Studio) и концепции исполняемых файлов агента репликации.

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

    2. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

      Дополнительные сведения об удалении реплика tion см. в разделе sp_removedbреплика tion (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

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

    Важно!

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

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

      Дополнительные сведения о запуске агент распространения см. в статьях "Запуск и остановка агента репликации" (SQL Server Management Studio) и концепции исполняемых файлов агента репликации.

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

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

      Дополнительные сведения о программе tablediff см. в статье "Сравнение реплицированных таблиц для различий (программирование репликации)".

    3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, синхронизируйте повторно метаданные издателя и распространителя с помощью хранимой процедуры sp_replrestart . Восстановление завершено. Если нет, перейдите к шагу d.

    4. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

      Дополнительные сведения об удалении реплика tion см. в разделе sp_removedbреплика tion (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

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

  1. Восстановите последнюю резервную копию базы данных публикации. Перейдите к шагу 2.

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

    Дополнительные сведения о запуске агент распространения см. в статьях "Запуск и остановка агента репликации" (SQL Server Management Studio) и концепции исполняемых файлов агента репликации.

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

  3. При использовании подписок, обновляемых в очереди, подключитесь к каждому подписчику и удалите все строки из таблицы MS репликаtion_queue (Transact-SQL) в базе данных подписки. Перейдите к шагу 4.

    Примечание.

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

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

    Важно!

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

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

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

      Дополнительные сведения о программе tablediff см. в статье "Сравнение реплицированных таблиц для различий (программирование репликации)".

    3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, синхронизируйте повторно метаданные издателя и распространителя с помощью хранимой процедуры sp_replrestart . Восстановление завершено. Если нет, перейдите к шагу d.

    4. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

      Дополнительные сведения об удалении реплика tion см. в статье и sp_removedbреплика tion (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

База данных публикации: одноранговая репликация транзакций

В следующих шагах базы данных публикаций A, Bи C находятся в топологии одноранговой репликации транзакций. Базы данных A и C находятся в режиме «в сети» и функционируют правильно; база данных B — восстанавливаемая база данных. Описанные здесь действия, особенно шаги 7, 10 и 11, очень похожи на процесс добавления узла к одноранговой топологии. Самый простой путь выполнения этих шагов — использование мастера настройки одноранговой топологии, однако можно использовать и хранимые процедуры.

  1. Запустите агент распространения, чтобы синхронизировать подписки в базах данных A и C. Перейдите к шагу 2.

    Дополнительные сведения о запуске агент распространения см. в статьях "Запуск и остановка агента репликации" (SQL Server Management Studio) и концепции исполняемых файлов агента репликации.

  2. Если база данных распространителя, которую использует B, по-прежнему доступна, выполните агент распространения для синхронизации подписок между базами данных B и A и базами данных и B и C. Перейдите к шагу 3.

  3. Удалите метаданные из базы данных распространителя, которую B использует, выполнив sp_removedistpublisherdbреплика tion в базе данных распространителя для B. Перейдите к шагу 4.

  4. В базах данных A и C удалите подписки на публикацию в базе данных B. Перейдите к шагу 5.

    Дополнительные сведения об удалении подписок см. в разделе Subscribe to Publications.

  5. Создайте резервную копию журнала или полную резервную копию базы данных A. Перейдите к шагу 6.

  6. Восстановите резервную копию базы данных A в базе данных B. База данных B теперь содержит данные из базы данных A, но не конфигурацию реплика. При восстановлении резервного копирования на другой сервер удаляется реплика tion; поэтому реплика tion было удалено из базы данных B. Перейдите к шагу 7.

  7. Повторно создайте публикацию в базе данных B, а затем повторно создайте подписки между базами данных A и B. (Подписки, включающие базу данных C обрабатывается на более позднем этапе.).

    1. Повторно создайте публикацию в базе данных B. Перейдите к шагу b.

    2. Создайте заново подписку в базе данных B на публикацию в базе данных A, указав, что подписка должна быть инициализирована с резервной копией (значение initialize with backup для параметра @sync_type хранимой процедуры sp_addsubscription). Перейдите к шагу c.

    3. Создайте заново подписку в базе данных A на публикацию в базе данных B, указав, что подписчик уже содержит данные (значение replication support only для параметра @sync_type хранимой процедуры sp_addsubscription). Перейдите к шагу 8.

  8. Запустите агент распространения, чтобы синхронизировать подписки в базах данных A и B. Если в опубликованных таблицах есть столбцы удостоверений, перейдите к шагу 9. Если нет, перейдите к шагу 10.

  9. После восстановления диапазон удостоверений, назначенный для каждой таблицы в базе данных A, также будет использоваться в базе данных B. Убедитесь, что восстановленная база данных B получила все изменения из неудавшихся баз данных B, которые были распространены в базу данных A и базу данных C; а затем переопределили диапазон удостоверений для каждой таблицы.

    1. Выполните процедуру sp_requestpeerresponse в базе данных B и получите выходной параметр @request_id. Перейдите к шагу b.

    2. По умолчанию агент распространителя работает непрерывно, поэтому токены отправляются на все узлы автоматически. Если агент распространителя не выполняется в непрерывном режиме, запустите его. Дополнительные сведения см. в разделе "Основные понятия агента репликации" или "Запуск и остановка агента репликации" (SQL Server Management Studio). Перейдите к шагу c.

    3. Выполните процедуру sp_helppeerresponses, указав значение @request_id, полученное в шаге b. Подождите, пока все узлы сообщат о получении однорангового запроса. Перейдите к шагу d.

    4. Выполните инструкцию DBCC CHECKIDENT для обновления начальных значений каждой таблицы в базе данных B , чтобы убедиться, что используется соответствующий диапазон. Перейдите к шагу 10.

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

  10. На этом этапе база данных B и база данных C не подключены напрямую, но они получат изменения через базу данных A. Если топология содержит все узлы, работающие под управлением SQL Server 2005 (9.x), перейдите к шагу 11; в противном случае перейдите к шагу 12.

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

    1. Остановите все действия в опубликованных таблицах в одноранговой топологии. Перейдите к шагу b.

    2. Выполните процедуру sp_requestpeerresponse в базе данных B и получите выходной параметр @request_id. Перейдите к шагу c.

    3. По умолчанию агент распространителя работает непрерывно, поэтому токены отправляются на все узлы автоматически. Если агент распространителя не выполняется в непрерывном режиме, запустите его. Перейдите к шагу d.

    4. Выполните процедуру sp_helppeerresponses, указав значение @request_id, полученное в шаге b. Подождите, пока все узлы сообщат о получении однорангового запроса. Перейдите к шагу e.

    5. Создайте заново подписку в базе данных B на публикацию в базе данных C, указав, что подписчик уже содержит данные. Перейдите к шагу b.

    6. Создайте заново подписку в базе данных C на публикацию в базе данных B, указав, что подписчик уже содержит данные. Перейдите к шагу 13.

  12. Создайте заново подписку между базами данных B и C.

    1. В базе данных Bвыполните запрос к таблице MSpeer_lsns , чтобы получить номер LSN последней транзакции, которая была передана в базу данных B из базы данных C.

    2. Создайте заново подписку в базе данных B на публикацию в базе данных C, указав, что подписка должна быть инициализирована на основе номера LSN (значение initialize from lsn для параметра @sync_type хранимой процедуры sp_addsubscription). Перейдите к шагу b.

    3. Создайте заново подписку в базе данных C на публикацию в базе данных B, указав, что подписчик уже содержит данные. Перейдите к шагу 13.

  13. Запустите агент распространения, чтобы синхронизировать подписки в базах данных B и C. Восстановление завершено.

База данных msdb (Издатель)

  1. Восстановите последнюю резервную копию базы данных msdb .

  2. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Создайте заново задание очистки подписки из скриптов репликации. Восстановление завершено.

База данных master (Издатель)

  1. Восстановите последнюю резервную копию базы данных master .

  2. Убедитесь, что база данных согласована с базой данных публикации по конфигурации и параметрам репликации.

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

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

  1. Восстановите последнюю резервную копию базы данных распространителя.

  2. Был ли перед сбоем включен параметр sync with backup для базы данных распространителя? Если да, перейдите к шагу 3, если нет — к шагу 4.

    Если параметр включен, запрос SELECT DATABASEPROPERTYEX('<DistributionDatabaseName>', 'IsSyncWithBackup') возвращает '1'.

  3. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 4.

  4. Либо сведения о конфигурации в восстановленной базе данных распространителя устарели, либо в базе данных распространителя не был установлен параметр sync with backup . (После восстановления база данных распространителя может пропустить транзакции, зафиксированные на издателе, но еще не доставлены подписчикам.) Удалите и повторно создайте реплика, а затем выполните проверку.

    1. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Перейдите к шагу b.

      Дополнительные сведения об удалении реплика tion см. в разделе sp_removedbреплика tion (Transact-SQL).

      Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

    2. Отметьте все публикации для проверки. Повторно инициализируйте все подписки, не прошедшие проверку. Восстановление завершено.

      Дополнительные сведения о проверке см. в разделе Validate Replicated Data. Дополнительные сведения о повторной инициализации см. в статье Повторная инициализация подписок.

База данных msdb (Распространитель)

  1. Восстановите последнюю резервную копию базы данных msdb .

  2. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех публикаций и подписок? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Удалите конфигурацию репликации с издателя, распространителя и подписчиков, затем создайте конфигурацию заново. При повторном создании подписок укажите, что подписчик уже содержит данные. Перейдите к шагу 4.

    Дополнительные сведения об удалении реплика tion см. в разделе sp_removedbреплика tion (Transact-SQL).

    Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

  4. Отметьте все публикации для проверки. Повторно инициализируйте все подписки, не прошедшие проверку. Восстановление завершено.

    Дополнительные сведения о проверке см. в разделе Validate Replicated Data. Дополнительные сведения о повторной инициализации см. в статье Повторная инициализация подписок.

База данных master (Распространитель)

  1. Восстановите последнюю резервную копию базы данных master .

  2. Убедитесь, что база данных согласована с базой данных публикации по конфигурации и параметрам репликации.

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

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

  1. Является ли последняя резервная копия базы данных подписки более поздней, чем значение параметра минимального срока хранения распространения в базе данных распространителя? (Это определяет, по-прежнему ли распространитель имеет все команды, необходимые для обновления подписчика.) Если да, перейдите к шагу 2. Если нет, выполните повторную инициализацию подписки. Восстановление завершено.

    Чтобы определить значение параметра срока хранения распространителя, выполните хранимую процедуру sp_helpdistributiondb и получите значение из столбца max_distretention (значение в часах).

    Дополнительные сведения о повторной инициализации подписки см. в разделе Reinitialize a Subscription.

  2. Восстановите последнюю резервную копию базы данных подписки. Перейдите к шагу 3.

  3. Если база данных подписки содержит только принудительные подписки, перейдите к шагу 4. Если база данных подписки содержит какие-либо подписки по запросу, задайте следующие вопросы. Актуальны ли сведения о подписке? Включает ли база данных все таблицы и параметры, которые были установлены на момент сбоя. Если да, перейдите к шагу 4. Если нет, выполните повторную инициализацию подписки. Восстановление завершено.

  4. Для синхронизации подписчика запустите агент распространителя. Восстановление завершено.

    Дополнительные сведения о запуске агент распространения см. в статьях "Запуск и остановка агента репликации" (SQL Server Management Studio) и концепции исполняемых файлов агента репликации.

База данных msdb (Подписчик)

  1. Восстановите последнюю резервную копию базы данных msdb . Используются ли на этом подписчике подписки по запросу? Если нет, восстановление завершено. Если да, перейдите к шагу 2.

  2. Является ли восстановленная резервная копия полной и содержащей последние данные? Содержит ли она последнюю конфигурацию всех подписок по запросу? Если да, восстановление завершено. Если нет, перейдите к шагу 3.

  3. Удалите и создайте заново подписки по запросу. При повторном создании подписок укажите, что подписчик уже содержит данные. Восстановление завершено.

    Дополнительные сведения об удалении подписок см. в разделе Subscribe to Publications.

    Дополнительные сведения о том, как указать, что у подписчика уже есть данные, см. в разделе Initialize a Subscription Manually.

База данных master (Подписчик)

  1. Восстановите последнюю резервную копию базы данных master .

  2. Убедитесь, что база данных согласована с базой данных публикации по конфигурации и параметрам репликации.

См. также

Резервное копирование и восстановление баз данных SQL Server
Создание резервных копий реплицируемых баз данных и восстановление из них
Настройка распространения
Публикация данных и объектов базы данных
Subscribe to Publications
Инициализация подписки
Синхронизация данных