次の方法で共有

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

適用対象:Azure SQL Managed Instance

この記事では、PowerShell、Azure CLI、または REST API を使用して、ユーザーが手動で開始したフェールオーバーを実行して Azure SQL Managed Instance を再起動する方法について説明します。

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

注

この記事のフェールオーバーは、SQL Server データベース エンジン プロセスの再起動を指し、 フェールオーバー グループのリージョン間フェールオーバーとは関係ありません。

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

可用性、SQL Managed Instance プラットフォームの基本的な部分は、SQL Server データベース エンジン プロセスをホストするローカルのスタンバイ計算ノードを提供することにより、データベース アプリケーションに対して透過的に機能します。 フェールオーバーは、SQL Server データベース エンジン プロセスがオフラインになり、同じコンピューティング ノードまたは別のコンピューティング ノードでオンラインになったときに発生します。 通常、フェールオーバーは、障害が検出されたとき、ノードが低下した場合、またはサービスの更新中に、Azure プラットフォームによって自動で管理されます。

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

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

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

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

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

サービス レベル 可用性モデル 予想されるフェールオーバー動作 可能性のあるフェールオーバーの動作 (例外的)
General Purpose ローカル冗長性
(単一の可用性ゾーン)		 SQL プロセスは同じ VM で再起動します。 SQL プロセスは別の VM で再起動します。
General Purpose ゾーン冗長性
(複数の可用性ゾーン)		 SQL プロセスは同じ VM で再起動します。 SQL プロセスは別の VM で再起動します。
ビジネスに不可欠 ローカル冗長性
(単一の可用性ゾーン)		 プライマリ レプリカで SQL プロシージャが再起動されるか、ランダム セカンダリ レプリカがプライマリに昇格されます。 該当なし
Business Critical ゾーン冗長性
(複数の可用性ゾーン)		 プライマリ レプリカで SQL プロシージャが再起動されるか、ランダム セカンダリ レプリカが同じ可用性ゾーンまたは異なる可用性ゾーンでプライマリに昇格されます。 該当なし

アクセス許可

フェールオーバーを開始するユーザーには、次のいずれかの 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。
  • 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 サービス レベルでインスタンスのフェールオーバーを開始する前と後にこのクエリを実行し、フェールオーバー操作の進行状況を監視します。

ビジネスクリティカル サービス層

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

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

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

メモ

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

制限事項

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

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

関連するコンテンツ