Мы недавно обновили несколько систем до SQL Server 2025. Само обновление ядра прошло гладко, но в наших контурах предварительной подготовки, когда мы планировали переход в прод, возникли три неожиданные проблемы. Ни одна из них не помешала завершению обновления, но все три могли легко сорвать в остальном плавное обновление на месте до SQL Server 2025. Что это были за проблемы и как можно избежать их возникновения?
На две конкретные функции повлияли изменения, которых можно ожидать, только если тщательно прочитать заметки о выпуске, и новое поведение программы установки, которое определённо застало нас врасплох.
Связанные серверы
Большинство людей не любят связанные серверы; мы используем их в основном для внутренних межсерверных операций, таких как запуск задач обслуживания с центрального служебного экземпляра. Наши связанные серверы изначально были настроены с использованием SQL Native Client (SQLNCLI), который имел тенденцию игнорировать или подавлять многие ошибки проверки TLS. Во многих средах до сих пор не настроены надлежащие сертификаты, часто потому, что это сложнее, чем просто установить TrustServerCertificate=Yes (также известный как «просто доверься мне»).
Вы, вероятно, видели этот параметр; в более ранних версиях SQL Server, по мере того как различные части экосистемы становились более безопасными, вас заставляли добавлять его в строки подключения приложений и отмечать соответствующий флажок в диалоговом окне подключения Management Studio.
SQL Server 2025 ужесточает поведение TLS ещё больше, и теперь поставщики применяют строгую проверку сертификатов. Это может «укусить» вас после обновления или даже при обновлении side-by-side, если вы просто скопируете скрипт связанных серверов как есть и создадите их на новом экземпляре SQL Server 2025.
Ошибки связанных серверов
После обновления в нашей среде разработки мы начали видеть множество сбоев, связанных с TLS, включая:
Msg 7303, Level 16, State 1
Cannot initialize the data source object of OLE DB provider "MSOLEDBSQL" for linked server "<linked server name>".
TCP Provider: The certificate chain was issued by an authority which is not trusted.
Msg 10054, Level 20, State 0
A transport-level error has occurred when receiving results from the server.
Msg 17832, Level 20, State 18
The login packet used to open the connection is structurally invalid; the connection has been closed.
[SQL Server]The target principal name is incorrect
Чтобы защитить себя до обновления, вы можете сделать одно из двух:
- Убедитесь, что на всех ваших серверах установлены надлежащие сертификаты, и что подключения между ними работают без слепой настройки «просто доверься мне» (это также может включать исправление или повторное создание имён субъектов-служб). Подробности можно найти в этих рекомендациях и документации:
- Повторно создайте связанные серверы с использованием MSOLEDBSQL и настройки «просто доверься мне». Хотя эта настройка работает, к ней следует относиться как к флагу удобства, а не как к постоянной стратегии безопасности.
Щёлкните правой кнопкой мыши на связанном сервере в обозревателе объектов и выберите Script Linked Server As > Drop and Create To. Вот пример, который также указывает MultiSubnetFailover на случай, если вы связываетесь с прослушивателем группы доступности. Скрипт должен включать любые имена логинов связанного сервера (хотя вам нужно будет предоставить пароли для любых логинов SQL Server, так как они не скриптуются), а также любые нестандартные параметры сервера, которые вы используете (например, доступ к данным, rpc in/out и совместимость сортировки).
EXEC master.dbo.sp_dropserver
@server = N'',
@droplogins = N'droplogins';
EXEC master.dbo.sp_addlinkedserver
@server = N'',
@srvproduct = N'', /* должна быть пустая строка */
@provider = N'MSOLEDBSQL',
@datasrc = N'',
@provstr = N'TrustServerCertificate=Yes;MultiSubnetFailover=Yes;';
/* не забудьте вызовы sp_addlinkedsrvlogin и sp_serveroption */
В любом случае протестируйте каждый связанный сервер как до, так и после обновления. (В этой документации предполагается, что вы можете использовать флаг трассировки 17600 для сохранения старого поведения, но я не пробовал этого… и считал бы это худшим выбором.)
Полнотекстовый поиск
Мы используем полнотекстовый поиск лишь изредка, но после обновления все запросы с использованием соответствующих функций, таких как CONTAINS, перестали работать.
Основная проблема заключается в том, что SQL Server 2025 представляет новую версию полнотекстового индекса, но существующие каталоги остаются в версии 1 (единственной версии с SQL Server 2005), если вы не обновите их вручную. Кажется, не важно, какой параметр полнотекстового поиска вы выберете во время установки; существующие каталоги остаются в версии 1, если вы не обновите их вручную. И когда механизм пытается получить доступ к индексу старой версии, он завершается неудачей с ошибкой:
Msg 30010, Level 16, State 2
An error has occurred during the full-text query. Common causes include: word-breaking errors or timeout,
FDHOST permissions/ACL issues, service account missing privileges, malfunctioning IFilters, communication
channel issues with FDHost and sqlservr.exe, etc. If recently performed in-place upgrade to SQL2025,
For help please see https://aka.ms/sqlfulltext.
(Кстати, URL-адрес в сообщении об ошибке должен вести сюда: Full-Text queries and populations fail after upgrade.)
Самое простое исправление — просто перестроить эти индексы, но имейте в виду, что перестроение больших каталогов может быть трудоёмким и повлиять на ЦП и ввод-вывод. Протестируйте это перестроение вне продуктивной среды до дня обновления.
Сначала убедитесь, что ваша база данных поддерживает новую версию индекса:
SELECT value
FROM sys.database_scoped_configurations
WHERE name = N'FULLTEXT_INDEX_VERSION';
Если значение равно 1, а не 2, измените параметр на уровне базы данных для использования версии 2:
ALTER DATABASE SCOPED CONFIGURATION
SET FULLTEXT_INDEX_VERSION = 2;
Затем перестройте каждый каталог:
ALTER FULLTEXT CATALOG <имя полнотекстового каталога> REBUILD;
Если у вас много баз данных и много полнотекстовых индексов, да, это будет утомительно. И, к сожалению, это нельзя сделать до обновления, как в случае со связанными серверами. (В документации предлагается более быстрое исправление: найти двоичные файлы 2005 года и скопировать их в новую папку binn. Но это гораздо сложнее и попахивает техническим долгом).
Установка стала более разрушительной
Когда я обновляю или устанавливаю исправления вручную с помощью пользовательского интерфейса программы установки, мне нравится всё подготовить и ответить на все диалоговые окна, останавливаясь прямо на последнем шаге, где я могу просто нажать «Обновить» или «Обновить», когда буду готов. Я больше не могу рекомендовать делать это, поскольку это стало более навязчивым, чем раньше. Обновление с SQL Server 2022 до SQL Server 2025 намеренно перезапускает службу прямо здесь, во время фазы проверки работоспособности:
Момент во время проверки правил, когда я обнаружил, что программа установки перезапустила механизм.
Просматривая журналы установки (Detail.txt), я увидел следующую последовательность:
...
(28) <ts> Slp: Evaluating rule : Engine_IsLPIMEnabledForX64
...
(28) <ts> SQLEngine: --SqlServerServiceSCM: Stopping SQL Server Service and dependents
...
(28) <ts> Slp: Sco: Attempting to stop service with wait MSSQLSERVER, timeout 600, stop dependents True
...
(28) <ts> Slp: Sco: Service MSSQLSERVER stopped in less than 3 seconds
...
(28) <ts> SQLEngine: --SqlServerServiceSCM: Starting SQL via SCM ()...
(28) <ts> Slp: Sco: Attempting to start service MSSQLSERVER
...
(28) <ts> Slp: Sco: Service MSSQLSERVER started
...
(28) <ts> Slp: Evaluating rule : Engine_SqlEngineHealthCheck
(28) <ts> Slp: Rule running on machine: <сервер\имя экземпляра>
(28) <ts> Slp: Rule evaluation done : Succeeded
(28) <ts> Slp: Rule evaluation message: The SQL Server service can be restarted; or for a clustered instance, the SQL Server resource is online.
(28) <ts> Slp: Send result to channel : RulesEngineNotificationChannel
...
В наших локальной, разработческой и тестовой средах это не было большой проблемой, но это было неожиданно. Возможно, так было всегда, и я не заметил, или, возможно, это поведение изменилось, но ушли в прошлое дни, когда я мог быть проактивным. Обычно я доводил обновление или накопительный пакет обновления до самого последнего шага на нескольких машинах, задолго до времени, или пока ждал применения обновлений Windows, без какого-либо страха повлиять на SQL Server, пока я не нажимал эту последнюю кнопку.
Я также нашёл небольшую опечатку, не страшную, если только вы не разбираете логи в поисках этого текста:
(28) <ts> Slp: Sco: Service SQLSERVERAGENT aleady at stop state
Кроме того, на большинстве экземпляров служба перезапускалась в общей сложности три раза! Помимо указанного выше во время проверки правил, ещё два раза после нажатия кнопки:
...
(01) <ts> SQLEngine: --SqlEngineSetupPrivate: Upgrade: ShutdownInstance : Engine Configuration (NotClustered)
...
(01) <ts> SQLEngine: --SqlService: Stopping SQL Server Service
...
(01) <ts> Slp: Sco: Service MSSQLSERVER stopped in less than 3 seconds
...
... проходит две минуты ...
...
(01) <ts> Slp: Sco: Service MSSQLSERVER started
...
(01) <ts> SQLEngine: : Checking Engine checkpoint 'WaitSqlServerStartEvents'
(01) <ts> SQLEngine: --SqlServerServiceSCM: Stopping SQL Server Service and dependents
...
(01) <ts> SQLEngine: : Checking Engine checkpoint 'GetSqlServerProcessHandle_4'
(01) <ts> Slp: Sco: Attempting to stop service with wait MSSQLSERVER, timeout 600, stop dependents True
...
(01) <ts> Slp: Sco: Service MSSQLSERVER stopped in less than 3 seconds
...
(01) <ts> Slp: Sco: Service MSSQLSERVER started
...
Просто о чём стоит помнить, особенно если вы устанавливаете исправления на вторичные реплики группы доступности и у вас есть чувствительные мониторы на подключениях, установленных между различными репликами. И снова, возможно, так всегда и было (два перезапуска во время обновления), и я никогда не замечал. Это, казалось, не повлияло на сам процесс обновления, но для меня было удивительно, когда я обнаружил это после просмотра журналов.
Бонус: Новые параметры и функции для тестирования
Я большой поклонник чистого обновления, когда вы ничего больше не меняете — чтобы любые сбои можно было точно отнести к обновлению, а не к «ой, и я изменил ещё 7 вещей».
Однако до обновления вы должны протестировать некоторые из этих очень привлекательных переключателей и регуляторов в обновлённой среде ниже прода, чтобы знать, какие из них вы, возможно, захотите включить после завершения обновления.
- Уровень совместимости
Установите уровень совместимости 170, чтобы автоматически воспользоваться исправлениями процессора запросов и улучшениями IQP (примеры здесь) — после тестирования, конечно, и ознакомления с этими различиями. - Оптимизированные блокировки (Optimized Locking)
Эта функция значительно уменьшает блокировки и конфликты блокировок; я писал в блоге о том, как работает эта функция, когда она была впервые представлена в Azure SQL Database. Хотя она включена по умолчанию в новых базах данных, созданных в SQL Server 2025, вам необходимо явно включить её для обновлённых баз данных. Это та функция, которая, скорее всего, потребует наибольшего тестирования на совместимость с вашими приложениями и любыми инструментами поставщиков, которые отслеживают блокировки, блокировки и взаимоблокировки. Это также та функция, которую будет муторно включать — хотя она не требует эксклюзивного доступа для изменения, как некоторые другие параметры, она ждёт, пока не будет активных транзакций. Это может быть практически невозможно в некоторых средах с высокой нагрузкой. - Сжатие резервных копий
Установите сжатие резервных копий для использования ZSTD по умолчанию, особенно если вы записываете в S3 или хранилище BLOB-объектов — см. официальную информацию здесь и мои ранние тесты здесь. - Хранилище запросов для доступных для чтения вторичных реплик
Это позволяет использовать хранилище запросов и обратную связь по DOP там, где выполняются все ваши запросы, а не только запросы, которые выполняются только на первичной реплике. Если вы используете SQL Server 2022 и включили флаг трассировки 12606, который позволял использовать эту неподдерживаемую в продуктивной среде функцию в продуктивной среде, вы можете отключить его. - Регулятор ресурсов (Resource Governor)
Возможно, вы игнорировали эту функцию в прошлом, но стоит взглянуть на неё ещё раз, особенно если вы наконец-то в поддерживаемой Standard Edition. (Я годами утверждал, что клиентам Enterprise Edition эта функция не нужна; именно клиентам Standard Edition, которые не могут позволить себе бросать неограниченное оборудование на проблемы ресурсов и конфликтов). В SQL Server 2025 теперь можно использовать регулятор ресурсов для управления использованием tempdb, о чём Брент Озар рассказывает здесь.
Комментариев нет:
Отправить комментарий