CLI を使用して Azure Arc に間接的に接続された Azure SQL Managed Instance をアップグレードする

  • [アーティクル]

この記事では、Azure CLI (az) を使用して、間接的に接続された Azure Arc 対応データ コントローラーにデプロイされている SQL Managed Instance をアップグレードする方法について説明します。

前提条件

ツールをインストールする

この記事のタスクに進む前に、次のツールをインストールします。

arcdata 拡張機能のバージョンとイメージのバージョンは関連しています。 アップグレードするイメージのバージョンに対応する適切な arcdata 拡張機能のバージョンがあることを、バージョン ログで確認します。

制限事項

マネージド インスタンスをアップグレードする前に、Azure Arc データ コントローラーを新しいバージョンにアップグレードする必要があります。

Active Directory 統合が有効になっている場合は、マネージド インスタンスをアップグレードする前に、Active Directory コネクタを新しいバージョンにアップグレードする必要があります。

データ コントローラーをアップグレードする前に、マネージド インスタンスをデータ コントローラーおよび Active Directory コネクタと同じバージョンにする必要があります。

現時点では、バッチ アップグレード プロセスは使用できません。

マネージド インスタンスをアップグレードする

最初にドライランを実行できます。 ドライ ランにより、バージョン スキーマが検証され、アップグレードするインスタンスが一覧表示されます。

次に例を示します。

az sql mi-arc upgrade --name <instance name> --k8s-namespace <namespace> --dry-run --use-k8s

次のように出力されます。

Preparing to upgrade sql sqlmi-1 in namespace arc to data controller version.
****Dry Run****1 instance(s) would be upgraded by this commandsqlmi-1 would be upgraded to <version-tag>.

汎用

SQL Managed Instance General Purpose のアップグレード中は、ポッドが終了して新しいバージョンで再プロビジョニングされます。 それに起因し、新しいポッドが作成されるとき、わずかなダウンタウンが発生します。 中断を最小に抑えるため、接続再試行ロジックなど、アプリケーションに回復性を与える必要があります。 回復性の設計と Azure サービスの再試行ガイダンス の詳細については、「信頼性の重要な要素の概要」を参照してください。

Business Critical

複数のレプリカを使用した SQL Managed Instance Business Critical のアップグレード中は、次のことが行われます。

  • セカンダリ レプリカ ポッドが終了して新しいバージョンで再プロビジョニングされます
  • レプリカがアップグレードされると、プライマリはアップグレードされたレプリカにフェールオーバーされます
  • 以前のプライマリ ポッドが終了して、新しいバージョンで再プロビジョニングされ、セカンダリ になります

フェールオーバーが発生するとき、短時間のダウンタイムが発生します。

アップグレード

マネージド インスタンスをアップグレードするには、次のコマンドを使用します。

az sql mi-arc upgrade --name <instance name> --desired-version <version> --k8s-namespace <namespace> --use-k8s

例:

az sql mi-arc upgrade --name instance1 --desired-version v1.0.0.20211028 --k8s-namespace arc1 --use-k8s

モニター

CLI

show コマンドでアップグレードの進捗状況を監視できます。

az sql mi-arc show --name <instance name> --k8s-namespace <namespace> --use-k8s

出力

コマンドの出力に、リソース情報が表示されます。 状態にアップグレード情報が示されます。

アップグレード中は、State に Updating が表示されます。Running Version は現在のバージョンになります。

Status:
  Log Search Dashboard:  https://30.88.222.48:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqlmi-1'))
  Metrics Dashboard:     https://30.88.221.32:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqlmi-1-0
  Observed Generation:   2
  Primary Endpoint:      30.76.129.38,1433
  Ready Replicas:        1/1
  Running Version:       v1.0.0_2021-07-30
  State:                 Updating

アップグレードが完了すると、State に Ready が表示されます。Running Version は新しいバージョンになります。

Status:
  Log Search Dashboard:  https://30.88.222.48:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqlmi-1'))
  Metrics Dashboard:     https://30.88.221.32:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqlmi-1-0
  Observed Generation:   2
  Primary Endpoint:      30.76.129.38,1433
  Ready Replicas:        1/1
  Running Version:       <version-tag>
  State:                 Ready

トラブルシューティング

目的のバージョンが特定のバージョンに設定されている場合、ブートストラップ ジョブでは成功するまでそのバージョンへのアップグレードが試行されます。 アップグレードが成功すると、仕様の RunningVersion プロパティが新しいバージョンに更新されます。 イメージ タグが正しくない、レジストリまたはリポジトリに接続できない、コンテナーに割り当てられた CPU またはメモリが不足している、ストレージが不足しているなどのシナリオでは、アップグレードが失敗する可能性があります。

  1. 次のコマンドを実行して、いずれかのポッドで Error 状態が表示されているか、または再起動回数が多くなっているかを確認します。

    kubectl get pods --namespace <namespace>

  2. イベントを調べてエラーがあるかどうかを確認するには、以下を実行します

    kubectl describe pod <pod name> --namespace <namespace>

  3. ポッド内のコンテナーの一覧を取得するには、以下を実行します

    kubectl get pods <pod name> --namespace <namespace> -o jsonpath='{.spec.containers[*].name}*'

  4. コンテナーのログを取得するには、以下を実行します

    kubectl logs <pod name> <container name> --namespace <namespace>

一般的なエラーとそのトラブルシューティング方法を確認するには、「トラブルシューティング リソース」を参照してください。