Поделиться через

Обновление доставки журналов до SQL Server 2014 (Transact-SQL)

  • Статья

Конфигурации доставки журналов можно сохранить при обновлении с SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 или SQL Server 2012 до SQL Server 2014. В этом разделе описаны альтернативные сценарии и рекомендации по обновлению конфигурации доставки журналов.

Примечание

Сжатие резервной копии было введено в выпуске SQL Server 2008 Enterprise. В обновленной конфигурации доставки журналов используется параметр стандартного сжатия резервных копий уровня сервера, который управляет применением сжатия резервной копии к файлам резервной копии журнала транзакций. Режим сжатия резервной копии журналов можно указать отдельно для каждой конфигурации доставки журналов. Дополнительные сведения см. в статье Настройка доставки журналов (SQL Server).

Защита данных перед обновлением

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

Защита данных

  1. Создайте полную резервную копию каждой базы данных-источника.

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

  2. Выполните команду DBCC CHECKDB в каждой базе данных-источнике.

Обновление экземпляра сервера мониторинга

Существующий экземпляр сервера мониторинга можно обновить в любой момент.

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

Обновление конфигурации доставки журналов с одним сервером-получателем

Процесс обновления, описанный в этом разделе, предполагает работу с конфигурацией, которая состоит из сервера-источника и единственного сервера-получателя. Эта конфигурация показана на следующей иллюстрации, на которой изображен экземпляр сервера-источника (A) и экземпляр единственного сервера-получателя (Б).

Один сервер-получатель и без сервера мониторинга

Сведения об обновлении нескольких серверов-получателей см. в подразделе Обновление нескольких экземпляров серверов-получателейдалее в этом разделе.

Обновление экземпляра сервера-получателя

Процесс обновления включает обновление экземпляров сервера-получателя конфигурации доставки журналов SQL Server 2005 или более поздней версии до SQL Server 2014 до обновления экземпляра сервера-источника. Экземпляр сервера-получателя всегда следует обновлять первым. Если сервер-источник был обновлен до сервера-получателя, доставка журналов завершится ошибкой, так как резервная копия, созданная в более новой версии SQL Server, не может быть восстановлена в более старой версии SQL Server.

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

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

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

Примечание

Во время обновления сервера база данных-получатель не обновляется до базы данных SQL Server 2014. Ее обновление происходит только при переключении в режим «в сети».

Важно!

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

Обновление экземпляра сервера-источника

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

За счет более сложного процесса обновления можно повысить доступность базы данных, выполнив отработку отказа сервера-источника SQL Server 2005 или более поздней версии на сервер-получатель SQL Server 2014 перед обновлением исходного сервера-источника (сценарий 2, ниже). Существует два возможных сценария отработки отказа. Можно переключиться назад на исходный сервер-источник и сохранить первоначальную конфигурацию доставки журналов. В качестве альтернативного варианта можно удалить исходную конфигурацию доставки журналов до обновления исходного сервера-источника и позднее создать новую конфигурацию с помощью нового сервера-источника. В этом разделе описываются оба сценария.

Важно!

Экземпляр сервера-получателя следует обновлять обязательно до экземпляра сервера-источника. Дополнительные сведения см. в подразделе Обновление экземпляра сервера-получателяранее в этом разделе.

Сценарий 1. Обновление экземпляра сервера-источника без отработки отказа

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

Как только обновление сервера завершается, база данных автоматически переводится обратно в режим «в сети», в результате чего обновляется сама. После обновления базы данных возобновляют работу задания доставки журналов.

Сценарий 2. Обновление экземпляра сервера-источника с отработкой отказа

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

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

Важно!

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

Процедура 1. Управляемая отработка отказа на сервер-получатель

Управляемая отработка отказа на сервер-получатель.

  1. Вручную создайте резервную копию заключительного фрагмента журнала транзакций в базе данных-источнике с указанием WITH NORECOVERY. В эту резервную копию журналов попадут все записи, резервная копия которых еще не была создана, и база данных будет отключена. Обратите внимание, что пока база данных находится в режиме «вне сети», задание резервного копирования в доставке журналов будет завершаться с ошибкой.

    В приведенном ниже примере создается резервная копия заключительного фрагмента журнала базы данных AdventureWorks на сервере-источнике. Файлу резервной копии присваивается имя Failover_AW_20080315.trn:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO

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

  2. На сервере-получателе сделайте следующее.

    1. Убедитесь, что применены все резервные копии, созданные автоматически заданиями резервного копирования в доставке журналов. Чтобы проверка, какие задания резервного копирования были применены, используйте системную хранимую процедуру sp_help_log_shipping_monitor на сервере мониторинга или на сервере-источнике и сервере-получателе. Тот же файл должен быть указан в столбцах last_backup_file, last_copied_file и last_restored_file . Если какой-то из файлов резервной копии не был скопирован или из него не было выполнено восстановление, вручную вызовите задания копирования и восстановления агента для конфигурации доставки журналов.

      Дополнительные сведения о запуске задания см. в разделе Start a Job.

    2. Скопируйте заключительный файл резервной копии журнала, созданный в шаге 1, из общей папки в локальное расположение, которое используется для доставки журналов на сервере-получателе.

    3. Восстановите заключительную резервную копию журнала, указав предложение WITH RECOVERY, чтобы перевести базу данных в режим «в сети». В рамках подключения база данных будет обновлена до SQL Server 2014.

      В приведенном ниже примере выполняется восстановление из резервной копии заключительного фрагмента журнала базы данных AdventureWorks в базе данных-получателе. В примере используется параметр WITH RECOVERY, который переводит базу данных в режим «в сети»:

      RESTORE LOG AdventureWorks 
  FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
   WITH RECOVERY;
GO

      Примечание

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

    4. Перевод базы данных на другой ресурс путем перенаправления клиентов с исходного сервера-источника (сервера A) на подключенный сервер-получатель (сервер B).

    5. Убедитесь, чтобы журнал транзакций базы данных-получателя не заполнялся, когда база данных находится в режиме «в сети». Чтобы предотвратить заполнение журнала транзакций, можно создать его резервную копию. То есть рекомендуется сохранить его резервную копию в общем расположении, общей папке резервных копий, чтобы резервные копии были доступны для восстановления из копии на другом экземпляре сервера.

Процедура 2. Обновление исходного экземпляра сервера-источника до SQL Server 2014

После обновления исходного экземпляра сервера-источника до SQL Server 2014 база данных по-прежнему будет находиться в автономном режиме и в формате .

Процедура 3. Настройка доставки журналов в SQL Server 2014 г.

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

Переключение обратно на экземпляр исходного сервера-источника

  1. На промежуточном сервере-источнике (сервер B) создайте резервную копию заключительного фрагмента журнала с помощью параметра WITH NORECOVERY — будет создана резервная копия заключительного фрагмента журнала, а база данных перейдет в режим «вне сети». Резервная копия заключительного фрагмента журнала имеет имя Switchback_AW_20080315.trn. Например:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO

  2. Если в промежуточной базе данных-источнике создавались резервные копии журналов транзакций, отличные от резервной копии заключительного фрагмента журнала, созданной в шаге 1, выполните восстановление из этих копий с помощью параметра WITH NORECOVERY для базы данных в режиме «вне сети» на исходном сервере-источнике (сервер A). База данных обновляется до формата SQL Server 2014 года при восстановлении первой резервной копии журнала.

  3. Выполните восстановление из резервной копии заключительного фрагмента журнала (Switchback_AW_20080315.trn) в исходной базе данных-источнике (на сервере A) с помощью параметра WITH RECOVERY, чтобы перевести базу данных в режим в сети.

  4. Перейдите обратно к исходной базе данных-источнику (на сервере A) путем перенаправления клиентов с исходного сервера-источника на работающий в режиме «в сети» сервер-получатель.

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

Сохранение экземпляра прежнего сервера-получателя в качестве экземпляра нового сервера-источника

Создайте новую конфигурацию доставки журналов, используя экземпляр прежнего сервера-получателя, сервера B, в качестве нового сервера-источника и прежнего экземпляра сервера-источника, сервера A, в качестве нового сервера-получателя.

Важно!

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

  1. Чтобы не выполнять полное резервное копирование и восстановление базы данных на новом сервере-получателе (сервере A), примените резервные копии журналов из новой базы данных-источника к новой базе данных-получателю. В примере конфигурации выполняется восстановление из резервных копий журналов, созданных на сервере B, в базе данных на сервере A.

  2. Создание резервной копии журналов в новой базе данных-источнике (на сервере B).

  3. Восстановление из резервных копий журналов на экземпляре нового сервера-получателя (сервере A) с помощью параметра WITH NORECOVERY. Первая операция восстановления обновляет базу данных до SQL Server 2014.

  4. Настройте доставку журналов с прежним сервером-получателем (сервером B) в качестве экземпляра сервера-источника.

    Важно!

    Если вы используете SQL Server Management Studio, укажите, что база данных-получатель уже инициализирована.

    Дополнительные сведения см. в статье Настройка доставки журналов (SQL Server).

  5. Перевод базы данных на другой ресурс путем перенаправления клиентов с исходного сервера-источника (сервера A) на подключенный сервер-получатель (сервер B).

    Важно!

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

Обновление нескольких экземпляров серверов-получателей

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

Два сервера-получатели и без сервера мониторинга

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

Важно!

Экземпляры сервера-получателя всегда следует обновлять раньше, чем сервер-источник.

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

  1. Обновите все экземпляры сервера-получателя (сервер B и сервер C).

  2. Получите заключительный фрагмент журнала транзакций базы данных-источника (на сервере A) и переведите базу данных в режим «вне сети» путем создания резервной копии журнала транзакций с помощью параметра WITH NORECOVERY.

  3. На сервере-получателе, на который планируется выполнять переход (сервер B), переведите базу данных-получатель в режим «в сети» путем восстановления из резервной копии журналов с помощью инструкции WITH RECOVERY.

  4. На каждом сервере-получателе (сервер C) следует перевести базу данных-получатель в режим «вне сети» путем восстановления из резервной копии журналов с помощью предложения WITH NORECOVERY.

    Примечание

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

  5. Перевод базы данных на другой ресурс путем перенаправления клиентов с исходного сервера-источника (сервера A) на подключенный сервер-получатель (сервер B). База данных в режиме «в сети» становится промежуточным сервером-источником, благодаря которому база остается доступной, пока исходный сервер-источник (сервер A) находится в режиме «вне сети».

  6. Обновите исходный сервер-источник (сервер A).

  7. В базе данных, в которую была выполнена отработка отказа промежуточной базы данных-источника (на сервере B), вручную создайте резервную копию журнала транзакций с помощью with WITH NORECOVERY. При этом база данных перейдет в режим «вне сети».

  8. Выполните восстановление из всех резервных копий журналов транзакций, созданных в промежуточной базе данных-источнике (на сервере B) для всех прочих баз данных-получателей (на сервере C) с помощью параметра WITH NORECOVERY. Это позволяет продолжить доставку журналов из исходной базы данных-источника после ее обновления без необходимости выполнять полное восстановление в каждой базе данных-получателе.

  9. Восстановите журнал транзакций с промежуточного сервера-источника (сервера B) на исходной базе данных-источнике (на сервере A) с помощью параметра WITH RECOVERY.

Повторное развертывание доставки журналов

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

Сведения о включении доставки журналов см. в разделе Настройка доставки журналов (SQL Server)..

См. также:

Резервные копии журналов транзакций (SQL Server)Применение резервных копий журналов транзакций (SQL Server)Таблицы доставки журналов и хранимые процедуры