共用方式為

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

  • 問題與客戶影響：此錯誤導致 azdata bdc cp 命令在 HDFS 路徑之間隨機失敗。 Bug 會更頻繁地影響較大的檔案複本。

  • 解決方案：更新至累積更新 15（CU15）。

Log4j security

  • 受影響的版本：無

  • 問題和客戶影響：在完整地評估 SQL Server 2019 巨量數據叢集程式代碼基底之後，沒有識別出與 12 月回報的 log4j 弱點相關的風險。 CU15 包含控制平面中 ElasticSearch 實例的 log4j （2.17） 更新版本，以確保巨量數據叢集容器的靜態程式代碼分析不會觸發影像掃描警示。

  • 解決方案：一律將您的巨量數據叢集更新為最新版本。

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

  • 受影響的版本：版本 CU8 和先前版本

  • 問題和客戶影響：直接將 CU8 版本或更早版本的叢集升級到 CU9 以上的任何版本時，升級在監視階段失敗。

  • 解決方案：請先升級至 CU9。 然後從 CU9 升級至最新版本。

Kubernetes 1.21+ 版的 Kubernetes API 平臺

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

  • 問題和客戶效果：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 巨量數據叢集中使用 PolyBase CU10 連線到使用憑證進行使用 SHA1 演算法所建立通道加密的現有 SQL Server 實例時，您可能會發現下列錯誤：

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 .

  • 解決方案：由於Ubuntu20.04比舊版基底映像更高的安全性需求，因此不允許使用SHA1演算法的憑證使用遠端連線。 SQL Server 2005-2016 版的預設自我簽署憑證使用 SHA1 演算法。 如需這項變更的詳細資訊，請參閱 對 SQL Server 2017 中自我簽署憑證所做的變更。 在遠端 SQL Server 實例中，使用以至少 112 位安全性的演算法建立的憑證（例如 SHA256）。 針對生產環境，建議從證書頒發機構單位取得受信任的憑證。 基於測試目的，也可以使用自我簽署憑證。 若要建立自我簽署憑證，請參閱 PowerShell Cmdlet New-SelfSignedCertificate 或 certreq 命令。 如需在遠端 SQL Server 實例上安裝新憑證的指示，請參閱 啟用 Database Engine 的加密連線

復原時在 ElasticSearch 中收集的部分記錄遺失

  • 受影響的版本：影響現有的叢集，當升級至 CU9 失敗時，會導致復原或使用者將降級為舊版。

  • 問題與客戶影響：用於 Elasticsearch 的軟體版本已使用 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 版

  • 問題和客戶影響：執行 複製-記錄 命令假定在發出命令的客戶端電腦上已安裝客戶端工具版本 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 伺服器。 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 部署的新巨量數據叢集，網關用戶名稱不是 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 映像的新叢集和現有叢集

  • 問題和客戶影響：由於與用於收集Pod計量和主機節點計量的API telegraf 相關的安全性修正，客戶可能會注意到這些計量未被收集。 這在 SQL Server 2019 巨量數據叢集的新部署和現有部署中都可行（升級至 CU5 之後）。 由於修正，Telegraf 現在需要具有全叢集角色許可權的服務帳戶。 部署會嘗試建立必要的服務帳戶和叢集角色，但如果部署叢集或執行升級的用戶沒有足夠的許可權，部署/升級會繼續進行警告並成功，但不會收集 Pod 和節點計量。

  • 因應措施：您可以要求系統管理員建立角色和服務帳戶（部署/升級之前或之後），巨量數據叢集將會使用這些帳戶。 本文 說明如何建立所需的工件。

azdata bdc copy-logs 命令失敗

  • 受影響的版本：Azure Data CLI （azdata） 20.0.0 版

  • 問題和客戶效果：實作複製logs命令假設用戶端工具已安裝在用戶端電腦上。 如果您要對安裝在 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.

    當您在 Azure Kubernetes Service 中升級 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 的 pod 或每個 Zookeeper 實例的進程會被重新啟動數次。
    • 當 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 巨量數據叢集簡介。

  • Last updated on