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

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

При обновлении с SQL Server 2005, SQL Server 2008, 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.

Обновление конфигураций журналируемого взаимодействия с одним вторичным сервером

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

Один вторичный сервер и без сервера мониторинга

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

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

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

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

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

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

Замечание

Во время обновления сервера вторичная база данных не обновляется до базы данных SQL Server 2014. Обновление произойдёт только в том случае, если оно будет выведено в онлайн.

Это важно

Параметр RESTORE WITH STANDBY не поддерживается для базы данных, требующей обновления. Если резервная база данных была настроена с помощью RESTORE WITH STANDBY, журналы транзакций больше не могут быть восстановлены после обновления. Чтобы возобновить перемещение журналов в этой вторичной базе данных, вам необходимо снова настроить перемещение журналов на этом сервере ожидания. Дополнительные сведения о параметре STANDBY см. в разделе RESTORE Arguments (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 . Если какой-либо из файлов резервной копии не был скопирован и восстановлен, вручную вызовите задания агента по копированию и восстановлению для настройки отправки журналов.

      Сведения о запуске задания см. в разделе "Запуск задания".

    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. Переключение базы данных на резервный сервер путем перенаправления клиентов с основного сервера (сервера А) на вторичный сервер (сервер 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. Восстановите резервную копию tail-log Switchback_AW_20080315.trn в исходной базе данных (на сервере A) с помощью WITH RECOVERY, чтобы сделать базу данных доступной.

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

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

Чтобы сохранить старый экземпляр вторичного сервера в качестве нового экземпляра основного сервера.

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

Это важно

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

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

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

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

  4. Настройте перемещение журналов с бывшего второстепенного сервера (сервер B) в качестве основного сервера.

    Это важно

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

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

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

    Это важно

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

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

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

Два вторичных сервера и нет сервера мониторинга

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

Это важно

Всегда обновляйте все экземпляры вторичного сервера перед обновлением основного сервера.

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

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

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

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

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

    Замечание

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

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

  6. Обновите исходный первичный сервер (сервер А).

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

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

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

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

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

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

См. также

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

  • Last updated on