通过

SQL Server 2019 大数据群集平台已知问题

适用于：SQL Server 2019 (15.x)

Important

Microsoft SQL Server 2019 大数据群集已停用。 对 SQL Server 2019 大数据群集的支持已于 2025 年 2 月 28 日结束。 有关详细信息，请参阅Microsoft SQL Server 平台上的公告博客文章和大数据选项。

Known issues

使用带有随机故障的 azdata 的大型文件的 HDFS 副本

  • 受影响的版本：CU14

  • 问题和客户影响：这是一个 bug，导致 HDFS 路径间的 命令随机失败。 该 bug 会更常影响较大的文件副本。

  • 解决方案：更新到累积更新 15 (CU15)。

Log4j security

  • 受影响的版本：无

  • 问题和客户影响：在全面评估 SQL Server 2019 大数据群集代码库后，无法发现与 12 月报告的 log4j 漏洞相关的风险。 CU15 包括控制平面中 ElasticSearch 实例的 log4j (2.17) 的更新版本，以确保大数据群集容器的静态代码分析不会触发映像扫描警报。

  • 解决方案：始终将大数据群集更新到最新版本。

不支持将群集从 CU8 及更低版本升级到高于 CU9 的版本

  • 受影响的版本：CU8 及更低版本

  • 问题及其对客户的影响：将 CU8 或更低版本上的群集直接升级到任何高于 CU9 的版本时，从监视阶段开始升级就会失败。

  • 解决方案：先升级到 CU9。 然后，从 CU9 升级到最新版本。

采用 Kubernetes API 版本 1.21+ 的 Kubernetes 平台

  • 受影响的版本：所有版本

  • 问题及其对客户的影响：从 CU12 起，Kubernetes API 1.21 或更高版本不是 SQL Server 大数据群集已测试的配置。

SQL Server 机器学习服务上的 MicrosoftML 包

  • 受影响的版本：CU10、CU11、CU12 和 CU13

  • 问题和对客户的影响：SQL Server 机器学习服务上的一些 MicrosoftML R/Python 包不起作用。 它会影响所有 SQL Server 主实例。

未能连接到 SQL Server 2016 或更低版本的远程实例

  • 受影响的版本：CU10
  • 问题及其对客户的影响：在 SQL Server 2019 大数据群集 CU10 中使用 PolyBase 连接到现有 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 Cmdlet New-SelfSignedCertificate 或 certreq 命令。 有关在远程 SQL Server 实例上安装新证书的说明，请参阅启用到数据库引擎的加密连接

回滚时在 ElasticSearch 中收集的日志发生了部分丢失

  • 受影响的版本：现有群集（当未能升级到 CU9 导致回滚，或用户发出降级到较旧版本的命令时）。

  • 问题及其对客户的影响：用于弹性搜索的软件版本是使用 CU9 升级的，新版本无法向后兼容以前的日志格式/元数据。 如果 ElasticSearch 组件成功升级，但随后触发了回滚，则在 ElasticSearch 升级和回滚之间收集的日志会永久丢失。 如果你发出降级到较旧 SQL Server 2019 大数据群集 版本的命令（不建议），则存储在 Elasticsearch 中的日志将会丢失。 如果升级回到 CU9，则数据会还原。

  • 解决方法：如果需要，可以使用通过 azdata bdc debug copy-logs 命令收集的日志进行故障排除。

缺少 pod 和容器指标

  • 受影响的版本：升级到 CU9 时的现有群集和新群集

  • 问题及其对客户的影响：由于在 CU9 中升级了用于监视组件的 Telegraf 版本，在将群集升级到 CU9 版本时，你会注意到不会收集 pod 和容器指标。 这是因为，由于软件升级，用于 Telegraf 的群集角色定义中需要额外的资源。 如果部署群集或执行升级的用户没有足够的权限，部署/升级将在出现警告的情况下继续进行并成功完成，但不会收集 pod 和节点指标。

  • 解决方法：可以要求管理员创建或更新角色和相应的服务帐户（在部署/升级之前或之后），大数据群集将使用它们。 本文介绍了如何创建所需的项目。

发出 azdata bdc copy-logs 命令无法使日志被复制

  • 受影响的版本：Azure Data CLI (azdata) 版本 20.0.0

  • 问题及其对客户的影响：实现 copy-logs 命令的前提是假定 客户端工具版本 1.15 或更高版本已安装在发出该命令的客户端计算机上。 如果使用了 kubectl 版本 1.14，则 azdata bdc debug copy-logs 命令将会完成且不会失败，但不会复制日志。 当使用 --debug 标志运行时，可以在输出中看到此错误：源“.”无效。

  • 解决方法：在同一台客户端计算机上安装 工具版本 1.15 或更高版本，然后重新发出 kubectl 命令。 请参阅此处的说明，了解如何安装 kubectl。

无法为 SQL Server 主实例启用 MSDTC 功能

  • 受影响的版本：所有大数据群集部署配置（无论是何种版本）。

  • 问题及其对客户的影响：SQL Server 作为 SQL Server 主实例部署到大数据群集中后，无法启用 MSDTC 功能。 没有针对此问题的解决方法。

HA SQL Server 数据库加密密钥加密程序轮换

  • 受影响的版本：CU8 及所有更低版本。 CU9 已解决。

  • 问题及其对客户的影响：在使用 HA 部署 SQL Server 时，无法对加密数据库执行证书轮换。 如果对主池执行以下命令，则会出现错误消息：

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

    这没有影响，虽然此命令失败，但目标数据库加密是使用旧证书进行保留的。

在 CU8 上启用 HDFS 加密区域支持

  • 受影响的版本：专门从 CU6 或早期版本升级到 CU8 版本时，会出现这种情况。 执行 CU8+ 的新部署或直接升级到 CU9 时，不会出现这种情况。 CU10 或更高版本不受影响。

  • 问题和对客户的影响：在这种情况下，默认未启用 HDFS 加密区域支持，用户需要使用配置指南中提供的步骤进行配置。

应用累积更新前清空 Livy 作业

  • 受影响的版本：CU6 及所有更低版本。 已为 CU8 解决。

  • 问题及其对客户的影响：在升级过程中，sparkhead 返回 404 错误。

  • 解决方法：在升级大数据群集之前，请确保没有活动的 Livy 会话或批处理作业。 按照从支持的版本升级中的说明进行操作，以避免这种情况。

    如果在升级过程中 Livy 返回 404 错误，请在两个 sparkhead 节点上重启 Livy 服务器。 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 大数据群集 CU5 部署的新大数据群集，网关用户名不是 。 如果用于连接到网关终结点的应用程序使用的凭据错误，你将看到身份验证错误。 此更改是在大数据群集中以非根用户身份运行应用程序（一种从 SQL Server 大数据群集 CU5 版本开始的新默认行为，在使用 CU5 部署新的大数据群集时，网关终结点的用户名基于通过 AZDATA_USERNAME 环境变量传递的值）的结果。 网关终结点的用户名与用于控制器和 SQL Server 终结点的用户名相同。 这只会影响新部署。 使用任何之前版本部署的现有大数据群集将继续使用 root。 将群集部署为使用 Active Directory 身份验证时，不会对凭据产生任何影响。

  • 解决方法：Azure Data Studio 将以透明方式处理用于连接到网关的凭据的更改，以在对象资源管理器中启用 HDFS 浏览体验。 必须安装包括解决此用例所需的更改的最新 Azure Data Studio 版本。 对于必须提供凭才能通过网关访问服务的其他情况（例如使用 Azure Data CLI (azdata) 登录、访问 Spark 的 Web 仪表板），必须确保使用正确的凭据。 如果你的目标是在 CU5 之前部署的现有群集，则将继续使用 root 用户名连接到网关，即使是在将群集升级到 CU5 之后也是如此。 如果使用 CU5 版本部署新群集，请通过提供与 AZDATA_USERNAME 环境变量对应的用户名进行登录。

未收集的 pod 和节点指标

  • 受影响的版本：使用 CU5 映像的新群集和现有群集

  • 问题及其对客户的影响：由于与 telegraf 用于收集指标 pod 和主机节点指标的 API 相关的安全修补程序，客户可能会注意到未收集指标。 这在新的和现有的 SQL Server 2019 大数据群集 部署（升级到 CU5 之后）中都有可能发生。 由于该修补程序，Telegraf 现在需要具有群集范围的角色权限的服务帐户。 部署尝试创建必要的服务帐户和群集角色，但如果部署群集或执行升级的用户没有足够的权限，部署/升级将在出现警告的情况下继续进行并获得成功，但不会收集 pod 和节点指标。

  • 解决方法：可以要求管理员创建角色和服务帐户（部署/升级之前或之后），大数据群集将使用它们。 本文介绍了如何创建所需的项目。

azdata bdc copy-logs 命令失败

  • 受影响的版本：Azure Data CLI (azdata) 版本 20.0.0

  • 问题及其对客户的影响：copy-logs 命令的实现假定 客户端工具安装在发出该命令的客户端计算机上。 如果要针对安装在 OpenShift 上的大数据群集发出该命令，则在仅安装了 oc 工具的客户端上，你将收到错误：An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified。

  • 解决方法：在同一台客户端计算机上安装 工具，然后重新发出 kubectl 命令。 请参阅此处的说明，了解如何安装 kubectl。

通过专用存储库进行部署

  • 受影响的版本：GDR1、CU1、CU2。 CU3 已解决。

  • 问题及其对客户的影响：从专用存储库升级需要满足特定要求

  • 解决方法：如果使用专用存储库来预先拉取用于部署或升级大数据群集的映像，请确保当前版本映像和目标版本映像位于专用存储库中。 这样，在必要时可以成功回退。 此外，如果在原始部署后更改了专用存储库的凭据，请在升级之前更新 Kubernetes 中的相应密钥。 Azure Data CLI (azdata) 不支持通过 AZDATA_PASSWORD 和 AZDATA_USERNAME 环境变量来更新凭据。 使用 kubectl edit secrets 更新机密。

不支持对当前版本和目标版本使用不同存储库进行升级。

升级可能因超时而失败

  • 受影响的版本：GDR1、CU1、CU2。 CU3 已解决。

  • 问题及其对客户的影响：升级可能因超时而失败。

    下面的代码显示了提示失败的消息：

    > 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.

    在 Azure Kubernetes 服务 (AKS) 中升级 SQL Server 2019 大数据群集 时，更有可能出现此错误。

  • 解决方法：增加升级的超时时间值。

    若要增加升级的超时时间值，请编辑升级配置映射。 编辑升级配置映射：

    1. 运行下面的命令：

      kubectl edit configmap controller-upgrade-configmap

    2. 编辑以下字段：

      controllerUpgradeTimeoutInMinutes 指定等待控制器或控制器 db 完成升级所需的分钟数。 默认值为 5。 至少更新为 20。

      totalUpgradeTimeoutInMinutes：指定控制器和控制器 db 完成升级所需的总时间（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)

从 Azure Data Studio (ADS) 或 curl 提交 Livy 作业失败，出现 500 错误

  • 问题及其对客户的影响：在 HA 配置中，Spark 共享资源 sparkhead 配置有多个副本。 在这种情况下，可能会遇到从 Azure Data Studio (ADS) 或 curl 提交 Livy 作业失败的问题。 如果 curl 到任何 sparkhead Pod 都会导致连接被拒绝，则可以验证该问题。 例如，curl https://sparkhead-0:8998/ 或 curl https://sparkhead-1:8998 返回 500 错误。

    在下列情况下会发生这种情况：

    • 每个 Zookeeper 实例的 Zookeeper Pod 或进程重启几次时。
    • 当 sparkhead Pod 和 Zookeeper Pod 之间的网络连接不可靠时。

  • 解决方法：重启两个 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 主实例中可用性组中的数据库一起使用

  • 问题及其对客户的影响：在 HA 配置中，由于每个副本上用于加密的主密钥不同，因此在故障转移后不能使用启用了加密的数据库。

  • 解决方法：此问题目前没有解决方法。 建议在准备好修复之前，不要在此配置中启用加密。

Related content

有关 SQL Server 2019 大数据群集的详细信息，请参阅 SQL Server 大数据群集简介。