Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
Применимо к:
SQL Server
Чтобы сохранить решение для аварийного восстановления журналов доставки, обновите или примените сервисные обновления в соответствующем порядке. Обновления обслуживания включают пакеты обновления или накопительные обновления.
Замечание
Обновленная конфигурация доставки журналов использует backup compression default параметр конфигурации уровня сервера для управления тем, используется ли сжатие резервных копий для файлов резервного копирования журналов транзакций. Можно указать поведение сжатия резервных копий журналов для каждой конфигурации доставки журналов. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).
Предпосылки
Перед началом работы ознакомьтесь со следующими важными сведениями.
| Статья | Description |
|---|---|
| Поддерживаемые обновления версий и выпусков | Убедитесь, что вы можете обновить нужную версию SQL Server из существующей операционной системы Windows и версии SQL Server. Например, невозможно выполнить обновление непосредственно из экземпляра SQL Server 2005 (9.x) до SQL Server 2025 (17.x). |
| Выбор метода обновления ядро СУБД | Выберите соответствующий метод обновления и шаги на основе проверки поддерживаемых обновлений версий и выпусков. Также рассмотрите другие компоненты, установленные в вашей среде, чтобы обновить компоненты в правильном порядке. |
| Планирование и проверка плана обновления ядра СУБД | Ознакомьтесь с заметками о выпуске и известными проблемами обновления, контрольным списком предварительного обновления и разработкой и тестированием плана обновления. |
| Требования к оборудованию и программному обеспечению для установки SQL Server | Ознакомьтесь с требованиями к программному обеспечению для установки SQL Server. Если требуется другое программное обеспечение, установите его на каждом узле перед началом процесса обновления, чтобы свести к минимуму время простоя. |
| Поддержка автономной группы доступности, добавленная в SQL Server 2022 (16.x) | Если вы хотите начать использовать изолированные группы доступности с журналом доставки, необходимо удалить и заново создать топологию журналов доставки. Однако если вы уже используете изолированные группы доступности с пересылкой журналов транзакций, обновления поддерживаются. |
| Добавлена поддержка TDS 8.0 в SQL Server 2025 (17.x) | Если вы хотите использовать TDS 8.0 с доставкой журналов в SQL 2025 и более поздних версиях, сначала необходимо удалить имеющуюся конфигурацию доставки журналов. |
Защита данных перед обновлением
Чтобы защитить данные во время обновления доставки журналов, выполните следующие действия.
Выполните полную резервную копию базы данных в каждой базе данных-источнике.
Дополнительные сведения см. в статье Создание полной резервной копии базы данных (SQL Server).
Выполните команду 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).
Обновление экземпляра основного сервера
Так как доставка журналов в основном является решением аварийного восстановления, самый простой и наиболее распространенный сценарий заключается в обновлении основного экземпляра на месте. База данных недоступна во время этого обновления. После обновления сервера база данных автоматически возвращается в режим "в сети", что приводит к обновлению. После обновления базы данных задания доставки журналов возобновляются.
Доставка журналов также поддерживает возможность переключения на вторичный сервер доставки журналов и при необходимости преобразовывать роли между основными и вторичными серверами доставки журналов.
Однако, поскольку лог-шиппинг (пересылка журналов) редко конфигурируется как решение для высокой доступности (новые варианты гораздо более надежные), переключение на резервный узел обычно не сокращает время простоя. Объекты системной базы данных не синхронизированы и позволяют клиентам легко находить и подключаться к повышенной вторичной базе данных может быть сложной задачей.