Известные проблемы с платформой кластеров больших данных SQL Server 2019

Область применения: SQL Server 2019 (15.x)

Important

Кластеры больших данных Microsoft SQL Server 2019 прекращены. Поддержка кластеров больших данных SQL Server 2019 закончилась с 28 февраля 2025 г. Дополнительные сведения см. в записи блога объявлений и параметрах больших данных на платформе Microsoft SQL Server.

Known issues

Копирование больших файлов HDFS с помощью azdata с случайными сбоями

  • Затронутые выпуски: CU14

  • Проблема и влияние на клиента. Это была ошибка, приводившая к случайным сбоям команд azdata bdc cp между путями HDFS. Ошибка влияет на более крупные копии файлов чаще.

  • Решение: обновление до версии накопительного обновления 15 (CU15).

Log4j security

  • Затронутые выпуски: Нет

  • Проблема и влияние клиента. После тщательной оценки базы кода кластеров больших данных SQL Server 2019 не было обнаружено риска, связанного с уязвимостью log4j, сообщаемой в декабре. CU15 включает обновленную версию log4j (2.17) для экземпляра ElasticSearch в плоскости управления, чтобы гарантировать, что оповещения сканирования изображений не активируются статическим анализом кода контейнеров кластера больших данных.

  • Решение. Всегда обновляйте кластер больших данных до последней версии.

Обновление кластера с накопительного пакета обновления 8 и предыдущих версий до версий после CU9 не поддерживается.

  • Затронутые выпуски: CU8 и более ранние

  • Проблема и влияние на клиента: При обновлении кластера непосредственно с версии CU8 или предыдущих до любой версии выше CU9 происходит сбой на этапе мониторинга.

  • Решение: сначала обновите до CU9. Затем обновите с CU9 до последнего выпуска.

Платформы Kubernetes с API Kubernetes версии 1.21+

  • Затронутые выпуски: все выпуски

  • Проблема и влияние на клиента: API Kubernetes 1.21 или выше — это не проверенная конфигурация кластеров больших данных SQL Server по состоянию на CU12.

Пакеты MicrosoftML в службах машинного обучения SQL Server

  • Затронутые выпуски: CU10, CU11, CU12 и CU13

  • Проблема и влияние клиента: некоторые пакеты MicrosoftML R/Python в службах машинного обучения SQL Server не работают. Это влияет на все главные экземпляры SQL Server.

Не удалось подключиться к удаленному экземпляру SQL Server 2016 или более ранней версии

  • Затронутые выпуски: CU10
  • Проблема и влияние на клиента: При использовании PolyBase в кластерах больших данных SQL Server 2019 CU10 для подключения к существующему экземпляру SQL Server, который использует сертификат, созданный для шифрования каналов с помощью алгоритма SHA1, может произойти следующая ошибка:

Msg 105082, Level 16, State 1, Line 1 105082;Generic ODBC error: [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: An existing connection was forcibly closed by the remote host. Additional error <2>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection, SqlState: 08001, NativeError: 10054 Additional error <3>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server] Invalid connection string attribute, SqlState: 01S00, NativeError: 0 .

  • Решение. Из-за повышенных требований к безопасности Ubuntu 20.04 по сравнению с предыдущей версией базового образа удаленное подключение не допускается для сертификата с помощью алгоритма SHA1. Самозаверяющий сертификат SQL Server 2005-2016 по умолчанию использовал алгоритм SHA1. Дополнительные сведения об этом изменении см. в изменениях, внесенных в самозаверяющий сертификат в SQL Server 2017. В удаленном экземпляре SQL Server используйте сертификат, созданный с помощью алгоритма, использующего по крайней мере 112 бит безопасности (например, SHA256). Для рабочих сред рекомендуется получить доверенный сертификат из центра сертификации. Для тестирования также можно использовать самозаверяющий сертификат. Сведения о создании самозаверяющегося сертификата см. в командлете PowerShell New-SelfSignedCertificate или в команде certreq. Инструкции по установке нового сертификата на удаленном экземпляре SQL Server см. в разделе "Включение зашифрованных подключений к ядру СУБД"

Частичная потеря журналов, собранных в ElasticSearch при откате

  • Затронутые выпуски: затрагивает существующие кластеры, когда сбой обновления до CU9 приводит к откату или пользователь выполняет понижение до более старого выпуска.

  • Проблема и влияние на клиентов: версия программного обеспечения Elasticsearch была обновлена до CU9, и новая версия не совместима с форматом предыдущих логов или метаданными. Если компонент ElasticSearch успешно обновляется, но последующий откат активируется, журналы, собранные между обновлением ElasticSearch и откатом, окончательно теряются. Если вы выполните понижение версии до более ранней версии SQL Server 2019 Big Data кластеров больших данных (не рекомендуется), журналы, хранящиеся в Elasticsearch, будут потеряны. При обновлении до CU9 данные восстанавливаются.

  • Решение. При необходимости можно устранить неполадки с помощью журналов, собранных с помощью azdata bdc debug copy-logs команды.

Отсутствующие модули pod и метрики контейнеров

  • Затронутые релизы: существующие и новые кластеры после обновления до CU9

  • Проблема и влияние на клиента: В результате обновления версии Telegraf, используемой для мониторинга компонентов в CU9, вы заметите, что при обновлении кластера до версии CU9 выпуск, сбор метрик подов и контейнеров не производится. Это связано с тем, что в определении роли кластера, используемой для Telegraf, требуется дополнительный ресурс в результате обновления программного обеспечения. Если пользователь, развертывающий кластер или выполняющий обновление, не имеет достаточных разрешений, развертывание и обновление продолжается с предупреждением и успешно, но метрики pod и узлов не будут собраны.

  • Обходной путь. Вы можете попросить администратора создать или обновить роль и соответствующую учетную запись службы (до или после развертывания или обновления), а кластер больших данных будет использовать их. В этой статье описывается, как создать необходимые артефакты.

Выполнение команды azdata bdc copy-logs не приводит к тому, что журналы копируются.

  • Затронутые выпуски: Azure Data CLI (azdata) версии 20.0.0

  • Проблема и влияние клиента: реализация команды copy-logs предполагает kubectl установку клиентского средства версии 1.15 или более поздней версии на клиентском компьютере, с которого выдается команда. Если kubectl используется версия 1.14, azdata bdc debug copy-logs команда завершается без сбоев, но журналы не копируются. При выполнении с --debug флагом вы увидите эту ошибку в выходных данных: источник "." недопустим.

  • Решение. Установите kubectl средство версии 1.15 или более поздней версии на том же клиентском компьютере и повторно выполните azdata bdc copy-logs команду. Инструкции по установке см. kubectl.

Возможности MSDTC нельзя включить для главного экземпляра SQL Server

  • Затронутые выпуски: все конфигурации развертывания кластера больших данных независимо от выпуска.

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

Смена механизма шифрования ключа базы данных SQL Server

  • Затронутые выпуски: все версии до CU8. Устранено в CU9.

  • Проблема и влияние на клиента: При развертывании SQL Server с высокой доступностью, ротация сертификатов для зашифрованной базы данных не удается. При выполнении следующей команды в главном пуле появится сообщение об ошибке:

    ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER
CERTIFICATE <NewCertificateName>;

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

Включение поддержки зон шифрования HDFS в CU8

  • Затронутые выпуски: этот сценарий возникает при обновлении конкретно до выпуска CU8 из CU6 или предыдущей версии. Это не произойдет в новых развертываниях CU8+ или при обновлении непосредственно до CU9. Выпуски CU10 или более поздние версии не подвержены влиянию.

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

Очистите задания Livy перед применением накопительных обновлений

  • Затронутые выпуски: все версии до cu6. Устранено в CU8.

  • Проблема и влияние на клиента: во время обновления sparkhead возвращается ошибка 404.

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

    Если Livy возвращает ошибку 404 во время обновления, перезапустите сервер Livy на обоих sparkhead узлах. For example:

    kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy

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

  • Затронутые выпуски: все развертывания кластера больших данных с интеграцией Active Directory независимо от выпуска

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

  • Обходной путь. Обновите политику истечения срока действия учетных записей служб в кластере больших данных до значения "Срок действия пароля никогда не истекает" в контроллере домена. Полный список этих учетных записей см. в разделе "Автоматически созданные объекты Active Directory". Это действие можно выполнить до или после истечения срока действия. В последнем случае Active Directory повторно активирует пароли с истекшим сроком действия.

Учетные данные для доступа к службам через конечную точку шлюза

  • Затронутые выпуски: новые кластеры, развернутые начиная с CU5.

  • Проблема и влияние на клиента: Для новых кластеров больших данных, развернутых с помощью SQL Server Big Data Clusters CU5, имя пользователя шлюза не root. Если приложение, используемое для подключения к конечной точке шлюза, использует неправильные учетные данные, появится ошибка проверки подлинности. Это изменение связано с запуском приложений в кластере больших данных от имени пользователя без root-доступа (новое поведение по умолчанию, начиная с выпуска SQL Server Big Data Clusters CU5. При развертывании нового кластера больших данных с использованием CU5, имя пользователя для конечной точки шлюза основывается на значении, передаваемом через переменную среды AZDATA_USERNAME). Это то же имя пользователя, которое используется для конечных точек контроллера и SQL Server. Это влияет только на новые развертывания. Существующие кластеры больших данных, развернутые с любым из предыдущих выпусков, продолжают использовать root. Развертывание кластера с использованием проверки подлинности Active Directory не оказывает воздействия на учетные данные.

  • Решение: Azure Data Studio прозрачно обрабатывает изменения учетных данных для подключения к шлюзу, чтобы обеспечить возможность просмотра HDFS в обозревателе объектов. Необходимо установить последнюю версию Azure Data Studio , включающую необходимые изменения, которые относятся к этому варианту использования. В других сценариях, где необходимо предоставить учетные данные для доступа к службе через шлюз (например, вход с помощью Azure Data CLI (azdata), доступ к веб-панелям мониторинга для Spark), необходимо убедиться, что используются правильные учетные данные. Если вы нацеливаете существующий кластер, развернутый до обновления CU5, то продолжите использовать имя пользователя root для подключения к шлюзу, даже после его обновления до CU5. При развертывании нового кластера с помощью сборки CU5 войдите, указав имя пользователя, соответствующее AZDATA_USERNAME переменной среды.

Метрики подов и узлов не собираются

  • Затронутые выпуски: новые и существующие кластеры, использующие образы CU5

  • Проблема и влияние на клиента: В результате исправления безопасности, связанного с API, который использовался для сбора метрик pod и метрик узла хоста, клиенты могут заметить, что метрики не собираются. Это возможно как в новых, так и в существующих развертываниях кластеров больших данных SQL Server 2019 (после обновления до CU5). В результате исправления Telegraf теперь требует учетной записи службы с правами роли, охватывающими весь кластер. Развертывание пытается создать необходимую учетную запись службы и роль кластера, но если у пользователя, выполняющего развертывание или обновление кластера, недостаточно разрешений, процесс продолжается с предупреждением и считается успешным, однако метрики pod и узлов не будут собраны.

  • Обходной путь: Вы можете попросить администратора создать роль и учетную запись службы (либо до, либо после развертывания или обновления); кластер больших данных будет их использовать. В этой статье описывается, как создать необходимые артефакты.

сбой команды azdata bdc copy-logs

  • Затронутые выпуски: Azure Data CLI (azdata) версии 20.0.0

  • Проблема и влияние клиента: реализация команды copy-logs предполагает kubectl , что клиентское средство установлено на клиентском компьютере, с которого выдается команда. Если вы выдаете команду для кластера больших данных, установленного в OpenShift, из клиента, где установлен только oc инструмент, вы получите ошибку: An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified

  • Обходной путь: установите kubectl средство на одном клиентском компьютере и повторно выполните azdata bdc copy-logs команду. Инструкции по установке см. kubectl.

Развертывание с закрытым репозиторием

  • Затронутые выпуски: GDR1, CU1, CU2. Решено для CU3.

  • Проблема и влияние на клиента: Обновление из частного репозитория имеет определенные требования

  • Решение. Если вы используете частный репозиторий для предварительного извлечения образов для развертывания или обновления кластера больших данных, убедитесь, что текущие образы сборки и целевые образы сборки находятся в частном репозитории. При необходимости это обеспечивает успешный откат. Кроме того, если вы изменили учетные данные частного репозитория с момента первоначального развертывания, обновите соответствующий секрет в Kubernetes перед обновлением. Azure Data CLI (azdata) не поддерживает обновление учетных данных через переменные среды AZDATA_PASSWORD и AZDATA_USERNAME. Обновите секрет с помощью kubectl edit secrets.

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

Обновление может завершиться ошибкой из-за времени ожидания

  • Затронутые выпуски: GDR1, CU1, CU2. Устранено для CU 3.

  • Проблема и влияние на клиента: обновление может завершиться ошибкой из-за таймаута.

    В следующем коде показано, как может выглядеть сбой:

    > azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

    Эта ошибка, скорее всего, возникает при обновлении кластеров больших данных SQL Server 2019 в службе Azure Kubernetes (AKS).

  • Обходное решение. Увеличьте время ожидания обновления.

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

    1. Выполните следующую команду:

      kubectl edit configmap controller-upgrade-configmap

    2. Измените следующие поля:

      controllerUpgradeTimeoutInMinutes Указывает время ожидания завершения обновления контроллера или базы данных контроллера. Значение по умолчанию — 5. Обновите версию по крайней мере до 20.

      totalUpgradeTimeoutInMinutes: указывает общее время, необходимое для обновления контроллера и базы данных контроллера (controller + controllerdb обновление). Значение по умолчанию: 10. Обновите до не менее чем 40.

      componentUpgradeTimeoutInMinutes: указывает время завершения каждого последующего этапа обновления. Значение по умолчанию — 30. Обновление до 45.

    3. Сохраните и выйдите.

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

    from kubernetes import client, config
import json

def set_upgrade_timeouts(namespace, controller_timeout=20, controller_total_timeout=40, component_timeout=45):
     """ Set the timeouts for upgrades

     The timeout settings are as follows

     controllerUpgradeTimeoutInMinutes: sets the max amount of time for the controller
         or controllerdb to finish upgrading

     totalUpgradeTimeoutInMinutes: sets the max amount of time to wait for both the
         controller and controllerdb to complete their upgrade

     componentUpgradeTimeoutInMinutes: sets the max amount of time allowed for
         subsequent phases of the upgrade to complete
     """
     config.load_kube_config()

     upgrade_config_map = client.CoreV1Api().read_namespaced_config_map("controller-upgrade-configmap", namespace)

     upgrade_config = json.loads(upgrade_config_map.data["controller-upgrade"])

     upgrade_config["controllerUpgradeTimeoutInMinutes"] = controller_timeout

     upgrade_config["totalUpgradeTimeoutInMinutes"] = controller_total_timeout

     upgrade_config["componentUpgradeTimeoutInMinutes"] = component_timeout

     upgrade_config_map.data["controller-upgrade"] = json.dumps(upgrade_config)

     client.CoreV1Api().patch_namespaced_config_map("controller-upgrade-configmap", namespace, upgrade_config_map)

Отправка задания Livy из Azure Data Studio (ADS) или curl завершатся с ошибкой 500.

  • Проблема и влияние на клиента: В конфигурации высокой доступности общие ресурсы Spark настраиваются с несколькими репликами. В этом случае могут возникнуть сбои при отправке заданий Livy из Azure Data Studio (ADS) или curl. Чтобы проверить, curl к любому sparkhead pod приводит к отказу соединения. Например, curl https://sparkhead-0:8998/ или curl https://sparkhead-1:8998 возвращает ошибку 500.

    Это происходит в следующих сценариях:

    • Модули Zookeeper или процессы для каждого экземпляра Zookeeper перезапускаются несколько раз.
    • Если сетевое подключение ненадежно между модулем sparkhead и модулями Zookeeper.

  • Обходное решение. Перезапуск обоих серверов Livy.

    kubectl -n <clustername> exec sparkhead-0 -c hadoop-livy-sparkhistory supervisorctl restart livy

    kubectl -n <clustername> exec sparkhead-1 -c hadoop-livy-sparkhistory supervisorctl restart livy

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

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

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

Вставка в внешние таблицы с использованием режима проверки подлинности Active Directory

  • Проблема и влияние на клиентов: если главный экземпляр SQL Server находится в режиме проверки подлинности Active Directory, запрос, который выбирает только из внешних таблиц, где по крайней мере одна из внешних таблиц находится в пуле хранения, с последующей вставкой в другую внешнюю таблицу, запрос возвращает:

Msg 7320, Level 16, State 102, Line 1 Cannot execute the query "Remote Query" against OLE DB provider "SQLNCLI11" for linked server "SQLNCLI11". Only domain logins can be used to query Kerberized storage pool.

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

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

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

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

Related content

Дополнительные сведения о кластерах больших данных SQL Server 2019 см. в разделе "Общие сведения о кластерах больших данных SQL Server".

  • Last updated on