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

  • Статья

Применимо к:SQL Server

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

Примечание.

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

В этом разделе:

Необходимые компоненты

Перед установкой ознакомьтесь со следующими важными сведениями.

  • Supported Version and Edition Upgrades. Убедитесь, что текущая версия операционной системы Windows позволяет обновить текущую версию SQL Server до версии SQL Server 2016. Например, невозможно выполнить обновление непосредственно из экземпляра SQL Server 2005 до SQL Server 2019 (15.x).

  • Choose a Database Engine Upgrade Method. Выберите подходящий метод обновления с учетом сведений о поддерживаемых версиях и обновлениях выпуска, а также компонентах, установленных в среде и требующих обновления (это нужно, чтобы обеспечить правильный порядок обновления этих компонентов).

  • Составление и тестирование плана обновления Database Engine. Просмотрите заметки о выпуске и известные проблемы, связанные с обновлением, изучите контрольный список предварительных требований, а затем разработайте и протестируйте план обновления.

  • Требования к оборудованию и программному обеспечению для установки SQL Server 2016. Изучите требования к программному обеспечению для установки SQL Server. Если требуется дополнительное программное обеспечение, установите его на каждом узле перед запуском обновления, чтобы минимизировать время простоя.

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

Примечание.

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

Важно!

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

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

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

Примечание.

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

См. также

Обновление до SQL Server 2016 с помощью мастера установки (программа установки)
Установка SQL Server 2016 из командной строки
Настройка доставки журналов (SQL Server)
Наблюдение за доставкой журналов (Transact-SQL)
Таблицы доставки журналов и хранимые процедуры