次の方法で共有

ユーザー開始型の手動フェールオーバーでインスタンスの再起動 - Azure SQL Managed Instance

  • [アーティクル]

適用対象:Azure SQL Managed Instance

この記事では、PowerShell、Azure CLI、REST API を使用してセカンダリ計算ノードに手動のユーザー開始型フェールオーバーを実行することにより、Azure SQL Managed Instance を再起動する方法について説明します。

General Purpose (GP) と Business Critical (BC) サービス レベルでプライマリ ノードをフェールオーバー、ならびに BC サービス レベルでセカンダリの読み取り専用レプリカ ノードを手動でフェールオーバーすることは可能です。

Note

この記事で記述されるフェールオーバーとは、セカンダリ ノードで SQL Server データベース エンジン プロセスの開始を指しており、フェールオーバー グループのリージョン間フェールオーバーとは関係ありません。

どのようなときに手動フェールオーバーを使用するか

可用性、SQL Managed Instance プラットフォームの基本的な部分は、SQL Server データベース エンジン プロセスをホストするローカルのスタンバイ計算ノードを提供することにより、データベース アプリケーションに対して透過的に機能します。 フェールオーバーは、SQL Server データベース エンジン プロセスがプライマリ計算ノードでオフラインになり、セカンダリ計算ノードでオンラインになったときに発生します。 通常、SQL Managed Instance の計算ノード間のフェールオーバーは自動的に発生し、障害の検出、ノードの低下、毎月の定期的なソフトウェア更新時にプラットフォームで管理されます。

フェールオーバー操作全体は、SQL Server データベース エンジン プロセスをセカンダリ ノードでオンラインにし、データベースの状態を検証してから最終的にクライアント接続を新しいプライマリ ノードにリダイレクトする過程で構成されます。 クライアント接続は短期間 (通常は 1 分以内) でのみで失敗し、フェールオーバー操作の最終手順のときに発生します。

次の理由によって手動フェールオーバーを実行し、別のノードでエンジン プロセスを再起動できます。

  • 失敗したログイン、またはパフォーマンスの問題による低速。
  • 運用環境に展開する前に、アプリケーションのフェールオーバーの回復性をテストします。
  • 自動フェールオーバーによる障害回復性について、エンド ツー エンドのシステムをテストします。
  • 既存のデータベース セッションに対するフェールオーバーの影響をテストします。
  • クエリのパフォーマンスの低下 (インスタンスを再起動すると、パフォーマンスの問題を軽減できます)。

運用環境にデプロイする前にアプリケーションがフェールオーバー回復性を備えていることを確認するのは、運用環境でのアプリケーションの障害のリスクを軽減するのに役立ち、顧客に対するアプリケーションの可用性に寄与します。 次のビデオを使用し、アプリケーションのクラウドレディさをテストする方法について説明します。

次のテーブルでは、サービス レベルと 可用性モデルに基づくフェールオーバー操作中の SQL Managed Instance の予期される動作について説明します。

サービス レベル モデルの可用性 予想されるフェールオーバー動作 潜在的なフェールオーバー動作 (例外)
汎用 ローカル冗長性
(単一の可用性ゾーン)		 SQL プロセスは同じ VM で再起動します。 SQL プロセスは別の VM で再起動します。
汎用 ゾーン冗長 (プレビュー)
(複数の可用性ゾーン)		 SQL プロセスは同じ VM で再起動します。 SQL プロセスは別の VM で再起動します。
Business Critical ローカル冗長性
(単一の可用性ゾーン)		 ランダム セカンダリ レプリカはプライマリに昇格されました。 該当なし
Business Critical ゾーン冗長性
(複数の可用性ゾーン)		 ランダム セカンダリ レプリカは、同じ可用性ゾーンまたは異なる可用性ゾーンのいずれでプライマリに昇格されました。 該当なし

アクセス許可

フェールオーバーを開始するユーザーには、次のいずれかの Azure ロールが必要です。

  • サブスクリプションの所有者ロール、または
  • SQL Managed Instance 共同作成者ロールまたは
  • 次のアクセス許可を持つカスタム ロール:
    • Microsoft.Sql/managedInstances/failover/action

手動フェールオーバーでインスタンスの再起動

PowerShell、Azure CLI、REST API を使用することにより、インスタンスを手動フェールオーバーで再起動できます。

Az.Sql v2.9.0 以降のバージョンが必要です。 常に最新バージョンの PowerShell を使用できる Azure portal の Azure Cloud Shell を使用することを検討します。

前提条件として、次の PowerShell スクリプトを使用して必要な Azure モジュールをインストールします。 さらに、フェールオーバーする SQL Managed Instance が含まれるサブスクリプションを選択します。

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

(BC と GP 両方のサービス レベルに適用) プライマリ ノードのフェールオーバーを開始するには、次の例のように PowerShell コマンド Invoke-AzSqlInstanceFailover を使用します。

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

(BC サービス レベルのみに適用) 読み取りセカンダリ ノードをフェールオーバーするには、次の PowerShell コマンドを使用します。

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

フェールオーバーを監視する

ユーザー開始型フェールオーバーの進行状況の監視は、Business Critical サービス レベルと General Purpose サービス レベルのインスタンスによって異なります。

ユーザー開始型フェールオーバーの進行状況を監視するには、次のものを使用します。

  • General Purpose サービス レベルのシステムアップタイムを確認する sys.dm_os_sys_info。
  • Business Critical サービス レベルの利用可能なレプリカを確認する sys.dm_hadr_fabric_replica_states。

フェールオーバー プロセスの最終手順は、クライアント接続を新しいプライマリ ノードにリダイレクトすることです。 フェールオーバー中にクライアントの接続が短時間 (通常は 1 分未満) 失われる場合、サービス レベルとは関係なく、フェールオーバーが正常に実行されたことを示します。

汎用のサービス階層

次の T-SQL の例では、General Purpose サービス レベルのノードにおける SQL プロセスのアップタイムが示されています。

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

SQL プロセスの開始時刻は、ノードで SQL Server データベース エンジン プロセスが開始された時刻です。 フェールオーバーが完了したら、時刻が再開始されます。 General Purpose サービス レベルでインスタンスのフェールオーバーを開始する前と後にこのクエリを実行し、フェールオーバー操作の進行状況を監視します。

Business Critical サービス レベル

次の T-SQL の例は、現在、どのノードが Business Critical サービス レベルのプライマリ レプリカであるかを示しています。

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

フェールオーバーが完了したら、プライマリ レプリカをホストするノードが変更されます。 Business Critical サービス レベルでインスタンスのフェールオーバーを開始する前と後にこのクエリを実行し、フェールオーバー操作の進行状況を監視します。

Note

インスタンス エンジンは、フェールオーバーを開始する前にセカンダリ ノードのトランザクションがプライマリ ノードのトランザクションに追い付いていることを確認するため、大量のワークロード時に完全なフェールオーバー プロセスが完了するまでに数分かかる場合があります。

制限事項

ユーザー開始型の手動フェールオーバーにおける機能上の制限事項は次のとおりです。

  • 同じ SQL Managed Instance 上では、15 分ごとに 1 つのフェールオーバーのみを実行できます。
  • フェールオーバーは許可されていません。
    • 新しいデータベースの最初の完全バックアップが自動バックアップ システムによって完了するまで。
    • データベースの復元が進行中の場合。
  • Business Critical サービス レベルのインスタンスの場合
    • フェールオーバー要求が許可されるため、レプリカのクォーラムが存在している必要があります。
    • フェールオーバーを実行する読み取り可能セカンダリ レプリカを指定することはできません。

関連するコンテンツ