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

项目
12/04/2023

适用范围：SQL Server 2019 (15.x)

重要

Microsoft SQL Server 2019 大数据群集附加产品将停用。对 SQL Server 2019 大数据群集的支持将于 2025 年 2 月 28 日结束。具有软件保障的 SQL Server 2019 的所有现有用户都将在平台上获得完全支持，在此之前，该软件将继续通过 SQL Server 累积更新进行维护。有关详细信息，请参阅公告博客文章和 Microsoft SQL Server 平台上的大数据选项。

已知问题

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

受影响的版本：CU14
问题和客户影响：这是一个 bug，导致 HDFS 路径间的 azdata bdc cp 命令随机失败。该 bug 会更常影响较大的文件副本。
解决方案：更新到累积更新 15 (CU15)。

log4j 安全性

受影响的版本：无
问题和客户影响：在全面评估 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 命令的前提是假定 kubectl 客户端工具版本 1.15 或更高版本已安装在发出该命令的客户端计算机上。如果使用了 kubectl 版本 1.14，则 azdata bdc debug copy-logs 命令将会完成且不会失败，但不会复制日志。当使用 --debug 标志运行时，可以在输出中看到此错误：源“.”无效。
解决方法：在同一台客户端计算机上安装 kubectl 工具版本 1.15 或更高版本，然后重新发出 azdata bdc copy-logs 命令。请参阅此处的说明，了解如何安装 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 服务器。例如：
```
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 部署的新大数据群集，网关用户名不是 root。如果用于连接到网关终结点的应用程序使用的凭据错误，你将看到身份验证错误。此更改是在大数据群集中以非根用户身份运行应用程序（一种从 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 命令的实现假定 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。 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 大数据群集时，更有可能出现此错误。

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

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

运行以下命令：

kubectl edit configmap controller-upgrade-configmap

编辑以下字段：

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

totalUpgradeTimeoutInMinutes：指定控制器和控制器 db 完成升级所需的总时间（controller + controllerdb 升级）。默认值为 10。至少更新为 40。

componentUpgradeTimeoutInMinutes ：指定升级的每个后续阶段必须完成的时间量。默认值为 30。更新为 45。
保存并退出。

还可使用下面的 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 配置中，由于每个副本上用于加密的主密钥不同，因此在故障转移后不能使用启用了加密的数据库。
解决方法：此问题目前没有解决方法。建议在准备好修复之前，不要在此配置中启用加密。

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

通过

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

已知问题

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

log4j 安全性

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

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

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

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

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

缺少 pod 和容器指标

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

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

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

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

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

大数据群集生成的服务帐户密码过期

通过网关终结点访问服务所用的凭据

未收集的 pod 和节点指标

azdata bdc copy-logs 命令失败

通过专用存储库进行部署

升级可能因超时而失败

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

当主实例位于可用性组中时，创建内存优化表

在 Active Directory 身份验证模式下插入外部表

透明数据加密功能不能与 SQL Server 主实例中可用性组中的数据库一起使用

反馈

其他资源

通过

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

已知问题

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

log4j 安全性

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

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

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

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

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

缺少 pod 和容器指标

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

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

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

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

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

大数据群集生成的服务帐户密码过期

通过网关终结点访问服务所用的凭据

未收集的 pod 和节点指标

azdata bdc copy-logs 命令失败

通过专用存储库进行部署

升级可能因超时而失败

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

当主实例位于可用性组中时，创建内存优化表

在 Active Directory 身份验证模式下插入外部表

透明数据加密功能不能与 SQL Server 主实例中可用性组中的数据库一起使用

相关内容

反馈

其他资源