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
問題およびユーザーへの影響: これは、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 を使用してデプロイされた新しいビッグデータクラスターの場合、ゲートウェイのユーザー名は rootではありません。ゲートウェイエンドポイントへの接続に使用されるアプリケーションで間違った資格情報が使用されている場合、認証エラーが発生します。この変更は、ビッグデータクラスター内のアプリケーションを非ルートユーザーとして実行した結果 (SQL Server ビッグデータクラスター CU5 リリース以降の新しい既定の動作) であり、CU5 を使用して新しいビッグデータクラスターをデプロイする場合、ゲートウェイエンドポイントのユーザー名は AZDATA_USERNAME 環境変数を介して渡される値に基づくものになります。これは、コントローラーと SQL Server エンドポイントに使用されるのと同じユーザー名です。これは新しいデプロイにのみ影響します。以前のリリースのいずれかでデプロイされた既存のビッグデータクラスターでは引き続き root が使用されます。 Active Directory 認証を使用するためにクラスターがデプロイされている場合、資格情報には影響はありません。
回避策: オブジェクトエクスプローラーで HDFS ブラウズエクスペリエンスを有効にするためにゲートウェイに行われた接続に対する資格情報の変更は、Azure Data Studio によって透過的に処理されます。このユースケースに対処する必要な変更を含む、最新の Azure Data Studio リリースをインストールする必要があります。ゲートウェイ経由でサービスにアクセスするための資格情報を提供する必要があるその他のシナリオ (Azure Data CLI (azdata) でのログイン、Spark の Web ダッシュボードへのアクセスなど) では、正しい資格情報が確実に使用されるようにする必要があります。 CU5 より前にデプロイされた既存のクラスターを対象とする場合は、クラスターを CU5 にアップグレードした後でも、ゲートウェイへの接続には引き続き root ユーザー名を使用することになります。 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_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 (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 ジョブの送信でエラーが発生する可能性があります。確認するには、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 ビッグデータクラスターとは」を参照してください。

SQL Server 2019 ビッグデータクラスタープラットフォームの既知の問題

既知の問題

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

Log4j のセキュリティ

CU8 以前のリリースから CU9 以降のリリースへのクラスターのアップグレードがサポートされていない

Kubernetes API バージョン 1.21 以上を使用する Kubernetes プラットフォーム

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

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

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

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

azdata bdc copy-logs を実行しても、ログがコピーされない

SQL Server マスターインスタンスに対して MSDTC 機能を有効にできない

HA SQL Server データベースの暗号化キーの暗号化機能のローテーション

CU8 での HDFS 暗号化ゾーンのサポートの有効化

累積更新プログラムを適用する前の空の Livy ジョブ

ビッグデータクラスターによって生成されたサービスアカウントのパスワードの有効期限

ゲートウェイエンドポイント経由でサービスにアクセスするための資格情報

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

azdata bdc copy-logs コマンドの失敗

プライベートリポジトリを使用した展開

タイムアウトによりアップグレードが失敗することがある

Azure Data Studio (ADS) または curl からの Livy ジョブの送信が 500 エラーで失敗する

可用性グループのマスターインスタンスの場合にメモリ最適化テーブルを作成する

外部テーブルの Active Directory 認証モードに挿入する

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

フィードバック

フィードバック

その他のリソース

SQL Server 2019 ビッグ データ クラスター プラットフォームの既知の問題

既知の問題

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

Log4j のセキュリティ

CU8 以前のリリースから CU9 以降のリリースへのクラスターのアップグレードがサポートされていない

Kubernetes API バージョン 1.21 以上を使用する Kubernetes プラットフォーム

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

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

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

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

azdata bdc copy-logs を実行しても、ログがコピーされない

SQL Server マスター インスタンスに対して MSDTC 機能を有効にできない

HA SQL Server データベースの暗号化キーの暗号化機能のローテーション

CU8 での HDFS 暗号化ゾーンのサポートの有効化

累積更新プログラムを適用する前の空の Livy ジョブ

ビッグ データ クラスターによって生成されたサービス アカウントのパスワードの有効期限

ゲートウェイ エンドポイント経由でサービスにアクセスするための資格情報

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

azdata bdc copy-logs コマンドの失敗

プライベート リポジトリを使用した展開

タイムアウトによりアップグレードが失敗することがある

Azure Data Studio (ADS) または curl からの Livy ジョブの送信が 500 エラーで失敗する

可用性グループのマスター インスタンスの場合にメモリ最適化テーブルを作成する

外部テーブルの Active Directory 認証モードに挿入する

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

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

SQL Server 2019 ビッグデータクラスタープラットフォームの既知の問題

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

SQL Server マスターインスタンスに対して MSDTC 機能を有効にできない

ビッグデータクラスターによって生成されたサービスアカウントのパスワードの有効期限

ゲートウェイエンドポイント経由でサービスにアクセスするための資格情報

プライベートリポジトリを使用した展開

可用性グループのマスターインスタンスの場合にメモリ最適化テーブルを作成する

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