SQL Server 2019 ビッグ データ クラスター プラットフォームのリリース ノート

適用対象:yesSQL Server 2019 (15.x)

重要

Microsoft SQL Server 2019 ビッグ データ クラスターのアドオンは廃止されます。 SQL Server 2019 ビッグ データ クラスターのサポートは、2025 年 1 月 14 日に終了します。 ソフトウェア アシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。 詳細については、お知らせのブログ記事と「Microsoft SQL Server プラットフォームのビッグ データ オプション」を参照してください。

次のリリース ノートは、SQL Server 2019 ビッグ データ クラスターに適用されます。 この記事はリリースごとのセクションに分けられており、CU の変更点について説明しています。 この記事には、SQL Server 2019 ビッグ データ クラスターの最新リリースに関する既知の問題の一覧もあります。

テスト済み構成

SQL Server 2019 ビッグ データ クラスターは、Kubernetes によって調整された完全にコンテナー化されたソリューションです。 CU12 以降では、SQL Server ビッグ データ クラスターの各リリースは、コンポーネントの固定構成に対してテストされます。 この構成はリリースごとに評価され、Kubernetes が進化し続けるにつれて、エコシステムに合わせて調整が継続されます。

重要

Kubernetes はペースの速いエコシステムです。 セキュリティを確保し、SQL Server ビッグ データ クラスターのテスト済み構成上に存在するように、プラットフォームを最新の状態に保つことが重要です。

警告

累積的な更新プログラム 15 では、アップグレード順序が重要です。 Kubernetes クラスターをバージョン 1.21 にアップグレードする前に、ビッグ データ クラスターを CU15 にアップグレードしてください。 Kubernetes クラスターをバージョン 1.21 にアップグレードしてから BDC を CU14 または CU15 にアップグレードした場合、クラスターはエラー状態になり、BDC のアップグレードは成功しません。 この場合、Kubernetes をバージョン 1.20 に戻すと問題が解決します。

次の表には、SQL Server 2019 ビッグ データ クラスターの各リリースのテスト済み構成マトリックスが含まれています。

Release Container OS Kubernetes API ランタイム データ ストレージ ログ ストレージ
CU16 GDR Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
ブロックのみ ブロックのみ
CU16 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
ブロックのみ ブロックのみ
CU15 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
ブロックのみ ブロックのみ
CU14 Ubuntu 20.04 LTS 1.21 containerd 1.4.6
CRI-O 1.20.4
ブロックのみ ブロックのみ
CU13 Ubuntu 20.04 LTS 1.20 containerd 1.4.6
CRI-O 1.20.0
ブロックのみ ブロックのみ
CU12 Ubuntu 20.04 LTS 1.20 containerd 1.4.3
docker 20.10.2
CRI-O 1.20.0
ブロックのみ ブロックのみ

制限:

  • SQL Server 2019 ビッグ データ クラスターは、''ワークロード'' としてサポートされています。 Microsoft では、SQL Server 2019 ビッグ データ クラスターのみによってインストールおよび構成されたコンテナーのソフトウェア コンポーネントに対するサポートを提供しています。 Kubernetes 自体や、SQL Server 2019 ビッグ データ クラスターの動作に影響を与える可能性があるその他のコンテナーは、サポート チームによってサポートされていません。 Kubernetes のサポートについては、認定 Kubernetes 配布プロバイダーにお問い合わせください。
  • SQL Server 2019 ビッグ データ クラスターでは、すべての永続化ボリュームにブロック ストレージが必要です。 ビッグ データ クラスターによって作成および使用される永続化ボリュームの上での管理操作は、永続ボリューム (PV) を拡張する操作など、ストレージ プロバイダーに依存する機能です。 特定の CSI ストレージ プロバイダーのドキュメントまたはパートナーの参照アーキテクチャおよびホワイトペーパーを参照してください。
  • SQL Server 2019 ビッグ データ クラスターに含まれるオープン ソース コンポーネントは、その特定のリリースに対して固定されており、更新したり変更したりすることはできません。
  • コンテナー イメージは "現状のまま" 提供されます。 Kubernetes の構成可能性機能はサポートされていません。 SQL Server 2019 ビッグ データ クラスター リリースのコンテナー イメージ セットを変更する (つまり、コンテナーをカスタマイズする) ことはサポートされていません。

SQL Server ビッグ データ クラスター の参照アーキテクチャとホワイト ペーパーは、次のページにあります。

リリース履歴

SQL Server 2019 ビッグ データ クラスターのリリース履歴の一覧を次の表に示します。

リリース 1 SQL Server 2019 ビッグ データ クラスターでのバージョン Azure Data CLI (azdata) バージョン 2 リリース日
CU16 GDR KB 5014356 15.0.4236.7 20.3.12 2022 年 6 月 14 日
CU16 15.0.4223.1 20.3.11 2022 年 5 月 2 日
CU15 15.0.4198.2 20.3.10 2022 年 1 月 27 日
CU14 15.0.4188.2 20.3.9 2021 年 11 月 22 日
CU13 15.0.4178.15 20.3.8 2021 年 9 月 9 日
CU12 15.0.4153.13 20.3.7 2021 年 8 月 4 日
CU11 15.0.4138.2 20.3.5 2021 年 6 月 10 日
CU10 15.0.4123.1 20.3.2 2021 年 4 月 6 日
CU9 15.0.4102.2 20.3.0 2021 年 2 月 11 日
CU8-GDR 15.0.4083.2 20.2.6 2021 年 1 月 12 日
CU8 15.0.4073.23 20.2.2 2020 年 10 月 19 日
CU6 15.0.4053.23 20.0.1 2020 年 8 月 4 日
CU5 15.0.4043.16 20.0.0 2020 年 6 月 22 日
CU4 15.0.4033.1 15.0.4033 2020 年 3 月 31 日
CU3 15.0.4023.6 15.0.4023 2020 年 3 月 12 日
CU2 15.0.4013.40 15.0.4013 2020 年 2 月 13 日
CU1 15.0.4003.23 15.0.4003 2020 年 1 月 7 日
GDR1 15.0.2070.34 15.0.2070 2019 年 11 月 4 日

1 CU7 は SQL Server 2019 ビッグ データ クラスターでは使用できません。

2 Azure Data CLI (azdata) バージョンは、CU リリース時のツールのバージョンを反映しています。 azdata はサーバー リリースとは無関係でリリースされることもあります。そのため、最新のパッケージをインストールするとき、新しいバージョンが取得されることがあります。 新しいバージョンは、前にリリースされた CU との間に互換性があります。

更新プログラムのインストール方法

更新プログラムをインストールする方法については、「SQL Server ビッグ データ クラスターをアップグレードする方法」を参照してください。

既知の問題

azdata を使用した大規模ファイルの HDFS コピーでランダムに障害が発生する

  • 影響を受けるリリース: CU14

  • 問題およびユーザーへの影響: これは、HDFS パス間の azdata bdc cp コマンドでランダムに障害が発生するバグです。 このバグの影響をより頻繁に受けるのは、大規模ファイルのコピーです。

  • 解決策: 累積的な更新プログラム 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 プラットフォーム

  • 影響を受けるリリース: すべてのリリース

  • 問題およびユーザーへの影響: Kubernetes API 1.21 以上は、SQL Server ビッグ データ クラスターの CU12 の時点ではテスト済みの構成ではありません。

SQL Server Machine Learning Services での MicrosoftML パッケージ

  • 影響を受けるリリース: CU10、CU11、CU12、および CU13

  • 問題およびユーザーへの影響: SQL Server Machine Learning Services 上の一部の MicrosoftML R および Python パッケージが機能しません。 これは、すべての SQL Server マスター インスタンスに影響します。

SQL Server 2016 以前のリモート インスタンスへの接続に失敗する

  • 影響を受けるリリース: CU10
  • 問題およびユーザーへの影響: SQL Server 2019 ビッグ データ クラスター CU10 で PolyBase を使用して、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 .

  • 解決方法: Ubuntu 20.04 のセキュリティ要件が以前の基本イメージ バージョンより強化されているため、SHA1 アルゴリズムを使用する証明書に対してリモート接続は許可されません。 SQL Server リリース2005 から 2016 の既定の自己署名証明書では、SHA1 アルゴリズムが使用されていました。 この変更の詳細については、SQL Server 2017 で自己署名証明書に加えられた変更に関する記事を参照してください。 リモート SQL Server インスタンスで、112 ビット以上のセキュリティ (SHA256 など) を使用するアルゴリズムを使用して作成された証明書を使用してください。 運用環境では、証明機関から信頼された証明書を取得することをお勧めします。 テスト目的のため、自己署名証明書を使用することもできます。 自己署名証明書を作成するには、PowerShell コマンドレット New-SelfSignedCertificate または certreq コマンドに関するページを参照してください。 リモート SQL Server インスタンスに新しい証明書をインストールする手順については、「データベースエンジンへの暗号化接続の有効化」を参照してください。

Elasticsearch で収集されたログのロールバック時における部分的な損失

  • 影響を受けるリリース: CU9 へのアップグレードが失敗した結果としてロールバックが行われるとき、またはユーザーが古いリリースへのダウングレードを実行したとき、既存のクラスターに影響します。

  • 問題およびユーザーへの影響: Elastic Search に使用されるソフトウェアのバージョンは CU9 でアップグレードされましたが、新しいバージョンには以前のログ形式やメタデータとの下位互換性がありません。 Elasticsearch コンポーネントが正常にアップグレードされても、後でロールバックがトリガーされると、ElasticSearch のアップグレードからロールバックまでの間に収集されたログは完全に失われます。 古いバージョンの SQL Server 2019 ビッグ データ クラスターへのダウングレードを実行した場合 (推奨されません)、Elasticsearch に格納されていたログは失われます。 再び CU9 にアップグレードすると、データは復元されます。

  • 回避策:必要な場合は、azdata bdc debug copy-logs コマンドを使用して収集されたログを使用して、トラブルシューティングを行うことができます。

ポッドとコンテナーのメトリックが見つからない

  • 影響を受けるリリース: CU9 にアップグレードしたときの、既存および新規のクラスター

  • 問題およびユーザーへの影響: 監視コンポーネントに使用されている Telegraf のバージョンが CU9 でアップグレードされた結果、クラスターを CU9 リリースにアップグレードすると、ポッドとコンテナーのメトリックが収集されなくなります。 これは、ソフトウェアのアップグレードの結果として、Telegraf に使用されるクラスター ロールの定義に追加のリソースが必要になるためです。 クラスターをデプロイする、またはアップグレードを実行するユーザーに、十分なアクセス許可がない場合、デプロイまたはアップグレードは警告を伴って続行されて成功しますが、ポッドとノードのメトリックは収集されなくなります。

  • 回避策: (展開やアップグレードの前または後に) ロールとそれに対応するサービス アカウントの作成または更新を管理者に依頼します。そうすると、ビッグ データ クラスターでそれらが使用されるようになります。 この記事では、必要な成果物の作成方法について説明しています。

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 で解決されました。

  • 問題およびユーザーへの影響: SQL Server が HA と共に展開されている場合、暗号化されたデータベースの証明書ローテーションは失敗します。 マスター プールで次のコマンドを実行すると、エラー メッセージが表示されます。

    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 を使用してデプロイされた新しいビッグ データ クラスターの場合、ゲートウェイのユーザー名はルートではありません。 ゲートウェイ エンドポイントへの接続に使用されるアプリケーションで間違った資格情報が使用されている場合、認証エラーが発生します。 この変更は、ビッグ データ クラスター内のアプリケーションを非ルート ユーザーとして実行した結果 (SQL Server ビッグ データ クラスター CU5 リリース以降の新しい既定の動作) であり、CU5 を使用して新しいビッグ データ クラスターをデプロイする場合、ゲートウェイ エンドポイントのユーザー名は AZDATA_USERNAME 環境変数を介して渡される値に基づくものになります。 これは、コントローラーと SQL Server エンドポイントに使用されるのと同じユーザー名です。 これは新しい展開にのみ影響し、以前のリリースのいずれかでデプロイされた既存のビッグ データ クラスターでは引き続き、ルートが使用されます。 Active Directory 認証を使用するためにクラスターがデプロイされている場合、資格情報には影響はありません。

  • 回避策:ObjectExplorer で HDFS ブラウズ エクスペリエンスを有効にするためにゲートウェイに行われた接続に対する資格情報の変更は、Azure Data Studio によって透過的に処理されます。 このユース ケースに対処する必要な変更を含む、最新の Azure Data Studio リリースをインストールする必要があります。 ゲートウェイ経由でサービスにアクセスするための資格情報を提供する必要があるその他のシナリオ (Azure Data CLI (azdata) でのログイン、Spark の Web ダッシュボードへのアクセスなど) では、正しい資格情報が確実に使用されるようにする必要があります。 CU5 より前にデプロイされた既存のクラスターを対象とする場合は、クラスターを CU5 にアップグレードした後でも、ゲートウェイへの接続には引き続きルート ユーザー名を使用することになります。 CU5 ビルドを使用して新しいクラスターをデプロイする場合は、AZDATA_USERNAME 環境変数に対応するユーザー名を指定してサインインします。

ポッドとノードのメトリックが収集されない

  • 影響を受けるリリース: CU5 イメージを使用している新規および既存のクラスター

  • 問題およびユーザーへの影響: メトリック ポッドとホスト ノードのメトリックを収集するために telegraf によって使用されていた API に関するセキュリティ修正プログラムの結果として、メトリックが収集されなくなったことにお客様はお気付きかもしれません。 これは、(CU5 へのアップグレード後に) SQL Server 2019 ビッグ データ クラスターの新規および既存のデプロイの両方で発生する可能性があります。 この修正の結果として、Telegraf では、サービス アカウントにクラスター全体のロールのアクセス許可が必要になりました。 デプロイ時に、必要なサービス アカウントとクラスター ロールの作成が試行されます。しかし、クラスターをデプロイまたはアップグレードを実行するユーザーに十分なアクセス許可がない場合、デプロイまたはアップグレードは警告を伴って続行されますが、ポッドとノードのメトリックは収集されなくなります。

  • 回避策: (デプロイやアップグレードの前または後に) ロールとサービス アカウントの作成を管理者に依頼します。そうすると、ビッグ データ クラスターでそれらが使用されるようになります。 この記事では、必要な成果物の作成方法について説明しています。

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_PASSWORDAZDATA_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 (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 ジョブの送信でエラーが発生する可能性があります。 確認するには、sparkhead ポッドに curl を実行すると、接続が拒否されます。 たとえば、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 認証モードになっている場合、外部テーブルのうち少なくとも 1 つがストレージプール内にある場合に外部テーブルからのみ選択され、別の外部テーブルに挿入されるクエリでは、次のように返されます。

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.

  • 回避策:次のいずれかの方法でクエリを変更します。 ストレージ プール テーブルをローカル テーブルに結合するか、最初にローカル テーブルに挿入し、ローカル テーブルからデータを読み取ってデータ プールに挿入します。

Transparent Data Encryption 機能が、SQL Server のマスター インスタンスの可用性グループの一部であるデータベースで使用できない

  • 問題およびユーザーへの影響: HA 構成では、暗号化に使用されるマスター キーがレプリカごとに違うため、暗号化が有効になっているデータベースをフェールオーバー後に使用することはできません。

  • 回避策: この問題の回避策はありません。 修正が適用されるまでは、この構成では暗号化を有効にしないことをお勧めします。

次のステップ

SQL Server 2019 ビッグ データ クラスターの詳細については、「SQL Server ビッグ データ クラスターとは」を参照してください。