SQL Server ビッグ データ クラスターをアップグレードする方法
適用対象:
SQL Server 2019 (15.x)
重要
Microsoft SQL Server 2019 ビッグ データ クラスターのアドオンは廃止されます。 SQL Server 2019 ビッグ データ クラスターのサポートは、2025 年 2 月 28 日に終了します。 ソフトウェア アシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。 詳細については、お知らせのブログ記事と「Microsoft SQL Server プラットフォームのビッグ データ オプション」を参照してください。
アップグレード パスは、SQL Server ビッグ データ クラスターの現在のバージョンによって異なります。 一般配布リリース (GDR)、累積的な更新プログラム (CU)、または Quick Fix Engineering (QFE) 更新プログラムを含め、サポートされているリリースからアップグレードするには、インプレース アップグレードを行うことができます。 Community Technology Preview (CTP) またはリリース候補バージョンの BDC からのインプレース アップグレードはサポートされていません。 クラスターを削除し、再作成する必要があります。 次のセクションでは、各シナリオの手順について説明します。
Note
現在サポートされているビッグ データ クラスターの最も古いリリースは、SQL Server 2019 CU8 です。
アップグレードのリリース ノート
次に進む前に、既知の問題に関するアップグレードのリリース ノートを確認します。
警告
クラスターを最初に展開するときに、展開プロファイルの control.json ファイルでパラメーター imagePullPolicy を "Always" に設定する必要がありました。 このパラメーターは、展開の後で変更することはできません。
異なる値に設定した場合、アップグレード プロセスの間に予期しない結果が発生する可能性があり、クラスターの再展開が必要になります。
サポートされているリリースからのアップグレード
このセクションでは、SQL Server BDC を、サポートされているリリース (SQL Server 2019 GDR1 以降) から新しいサポートされているリリースにアップグレードする方法について説明します。
アクティブな Livy セッションがないことを確認します。
Azure Data Studio でアクティブな Livy セッションまたはバッチ ジョブが実行されていないことを確認します。 これを確認する簡単な方法は、
curlコマンドまたはブラウザーを使用して、次の URL を要求するというものです。<your-gateway-endpoint>/gateway/default/livy/v1/sessions<your-gateway-endpoint>/gateway/default/livy/v1/batches
SQL Server マスター インスタンスをバックアップします。
HDFS をバックアップします。
azdata bdc hdfs cp --from-path <path> --to-path <path>たとえば、次のように入力します。
azdata bdc hdfs cp --from-path hdfs://user/hive/warehouse/%%D --to-path ./%%DAzure Data CLI (
azdata) を更新します。Azure Data CLI (
azdata) のインストール手順に従います。Note
Azure Data CLI (
azdata) がpipと共にインストールされている場合は、Windows インストーラーまたは Linux パッケージ マネージャーを使ってインストールする前に、手動で削除する必要があります。ビッグ データ クラスターを更新します。
azdata bdc upgrade -n <clusterName> -t <imageTag> -r <containerRegistry>/<containerRepository>たとえば、次のスクリプトでは
2019-CU19-ubuntu-20.04イメージ タグを使用しています。azdata bdc upgrade -n bdc -t 2019-CU19-ubuntu-20.04 -r mcr.microsoft.com/mssql/bdc
Note
最新のイメージ タグは、SQL Server 2019 ビッグ データ クラスターのリリース ノートで入手できます。
重要
プライベート リポジトリを使用して BDC を展開またはアップグレードするためにイメージを事前にプルする場合は、現在のビルド イメージと > ターゲット ビルド イメージがプライベート リポジトリ内にあることを確認します。 これにより、必要な場合に正常にロールバックすることが可能になります。 また、最初の展開以降にプライベート リポジトリの >資格情報を変更した場合は、対応する環境変数 DOCKER_PASSWORD および >DOCKER_USERNAME を更新します。 現在のビルドとターゲット ビルドに異なるプライベート リポジトリを使用したアップグレードはサポートされていません。
アップグレードのタイムアウトを増やす
割り当てられた時間内に特定のコンポーネントがアップグレードされない場合、タイムアウトが発生する可能性があります。 次のコードにエラー例を示します。
>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.
アップグレードのタイムアウトを増やすには、 --controller-timeout と --component-timeout パラメーターを使用して、アップグレードの発行時に高い値を指定します。 このオプションは、SQL Server 2019 CU2 リリース以降でのみ使用できます。 たとえば、次のように入力します。
azdata bdc upgrade -t 2019-CU19-ubuntu-20.04 --controller-timeout=40 --component-timeout=40 --stability-threshold=3
--controller-timeout では、コントローラーまたはコントローラー db のアップグレードが完了するまでの待機時間を分単位で指定します。 --component-timeout では、これ以降のアップグレードの各フェーズの完了時間を指定します。
SQL Server 2019 CU19 リリースより前の場合にアップグレードのタイムアウトを増やすには、アップグレード構成マップを編集します。 アップグレード構成マップを編集するには:
次のコマンドを実行します。
kubectl edit configmap controller-upgrade-configmap
次のフィールドを編集します。
controllerUpgradeTimeoutInMinutes コントローラーまたはコントローラー db のアップグレードが完了するまでの待機時間を分単位で指定します。 既定値は 5 です。 20 以上に更新します。 totalUpgradeTimeoutInMinutes:コントローラーとコントローラー db の両方のアップグレード (コントローラー + コントローラー db のアップグレード) が完了するまでの合計時間を指定します。既定値は 10 です。 40 以上に更新します。 componentUpgradeTimeoutInMinutes:アップグレードの後続の各フェーズが完了するまでの時間を指定します。 既定値は 30 です。 45 に更新します。
保存して終了します。
CTP またはリリース候補からの BDC 展開の更新
SQL Server ビッグ データ クラスターの CTP またはリリース候補ビルドからのインプレース アップグレードはサポートされていません。 次のセクションでは、クラスターを手動で削除し、再作成する方法について説明します。
以前のクラスターをバックアップして削除する
SQL Server 2019 GDR1 リリースの前に展開されたビッグ データ クラスターのインプレース アップグレードはありません。 新しいリリースにアップグレードする唯一の方法は、クラスターを手動で削除して再作成することです。 各リリースには、以前のバージョンと互換性のない固有のバージョンの Azure Data CLI (azdata) があります。 また、別の以前のバージョンで展開されたクラスターに新しいコンテナー イメージをダウンロードした場合、最新のイメージはクラスター上の以前のイメージと互換性がない可能性があります。 コンテナー設定の展開構成ファイルで latest イメージ タグを使用している場合は、新しいイメージがプルされます。 既定では、各リリースには、SQL Server のリリース バージョンに対応する固有のイメージ タグがあります。 最新のリリースにアップグレードするには、次の手順に従います。
以前のクラスターを削除する前に、SQL Server マスター インスタンス上と HDFS 上のデータをバックアップします。 SQL Server マスター インスタンスの場合は、SQL Server のバックアップと復元を使用できます。 HDFS の場合は、
curlを使用してデータをコピーできます。azdata delete clusterコマンドを使用して、古いクラスターを削除します。azdata bdc delete --name <old-cluster-name>重要
クラスターと一致するバージョンの Azure Data CLI (
azdata) を使用します。 新しいバージョンの Azure Data CLI (azdata) で古いクラスターを削除しないでください。Note
azdata bdc deleteコマンドを発行すると、そのビッグ データ クラスター名で示される名前空間内で作成されたすべてのオブジェクトは削除されますが、名前空間自体は削除されません。 名前空間は、空で、他のアプリケーションが中に作成されていない限り、後の展開に再利用できます。以前のバージョンの Azure Data CLI (
azdata) をアンインストールします。pip3 uninstall -r https://azdatacli.blob.core.windows.net/python/azdata/2019-rc1/requirements.txt最新バージョンの Azure Data CLI (
azdata) をインストールします。 次のコマンドでは、最新のリリースから Azure Data CLI (azdata) がインストールされます。Windows:
pip3 install -r https://aka.ms/azdataLinux:
pip3 install -r https://aka.ms/azdata --user重要
各リリースで、Azure Data CLI (
azdata) のn-1バージョンへのパスが変更されます。 以前に Azure Data CLI (azdata) をインストールしている場合でも、新しいクラスターを作成する前に、最新のパスから再インストールする必要があります。
azdata のバージョンを確認する
新しいビッグ データ クラスターを展開する前に、--version パラメーターを指定して、最新バージョンの Azure Data CLI (azdata) を使用していることを確認します。
azdata --version
新しいリリースをインストールする
以前のビッグ データ クラスターを削除し、最新の Azure Data CLI (azdata) をインストールしたら、現在の展開手順に従って、新しいビッグ データ クラスターを展開します。 詳細については、「Kubernetes に SQL Server ビッグ データ クラスターを展開する方法」を参照してください。 次に、必要なデータベースまたはファイルを復元します。
次のステップ
ビッグ データ クラスターの詳細については、SQL Server ビッグ データ クラスター とはの概要に関するページを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示