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
問題和對客戶的影響：這是造成 azdata bdc cp 命令在 HDFS 路徑之間發生隨機失敗的錯誤。錯誤會更頻繁影響較大型的檔案複本。
解決方法：更新至累積更新 15 (CU15)。

Log4j 安全性

受影響的版本：無
問題和對客戶的影響：在徹底評估 2019 SQL Server 2019 巨量資料叢集程式碼基底之後，不會發現與 12 月回報的 log4j 弱點相關的風險。 CU15 包含控制平面中 ElasticSearch 執行個體的 log4j (2.17) 更新版本，可確保巨量資料叢集容器的靜態程式碼分析不會觸發映像掃描警示。
解決方法：一律將巨量資料叢集更新為最新版本。

不支援從 CU8 和舊版本升級至 CU9 後版本的叢集

受影響的版本：CU8 和先前版本
問題和對客戶的影響：直接將 CU8 版本或先前版本的叢集升級至任何上述 CU9 版本時，升級會從監視階段失敗。
解決方法：先升級至 CU9。然後再從 CU9 升級至最新版本。

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

受影響的版本：所有版本
問題和對客戶的影響：Kubernetes API 1.21 或更高版本不是截至 CU12 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 版本時，若升級用於 CU9 中監視元件的 Telegraf 版本，會導致系統不收集 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 旗標執行時，您可以在輸出中看到此錯誤：source '.' is invalid。
因應措施：在相同的用戶端電腦上安裝 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 之前部署的現有叢集，即使叢集升級至 CU5，仍會繼續使用 root 使用者名稱來連線到閘道。如果使用 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 用戶端工具已安裝在發出命令的用戶端電腦上。如果您是從僅安裝 oc 工具的用戶端，針對安裝在 OpenShift 上的巨量資料叢集發出命令，您將會收到錯誤：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 Service (AKS) 中升級 SQL Server 2019 巨量資料叢集時，很可能會發生此錯誤。

因應措施：增加升級的逾時。

若要增加升級的逾時，請編輯升級設定對應。編輯升級設定對應：

執行以下命令：

kubectl edit configmap controller-upgrade-configmap

編輯下列欄位：

controllerUpgradeTimeoutInMinutes 指定等待控制器或控制器資料庫完成升級的分鐘數。預設值為 5。更新為至少 20。

totalUpgradeTimeoutInMinutes：指定控制器與控制器資料庫完成升級的合併時間量 (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 作業失敗。若要確認，則對任何 sparkhead Pod 執行 curl 都會導致拒絕連線。例如，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 主要執行個體中可用性群組的資料庫使用

相關內容

意見反映

更多資源