次の方法で共有


リンクのトラブルシューティング - Azure SQL Managed Instance

適用対象:Azure SQL Managed Instance

この記事では、SQL Server と Azure SQL Managed Instance 間のリンクに関する問題を監視し、トラブルシューティングする方法について説明します。

Transact-SQL (T-SQL)、Azure PowerShell、または Azure CLI を使用してリンクの状態を確認できます。 問題が発生した場合は、エラー コードを使用して問題をトラブルシューティングすることができます。

リンクの作成に関する問題の多くは、2 つのインスタンス間のネットワークを確認し、リンクに合わせて環境が適切に準備されていることを確認することで解決できます。

初期シード処理

SQL Server と Azure SQL Managed Instance の間にリンクを確立する場合、データ レプリケーションが開始される前に、最初のシード処理フェーズがあります。 初期シード処理フェーズは、最も時間がかかり、最も負荷の高い操作です。 初期シード処理が完了すると、データは同期され、その後はそれ以降のデータ変更のみがレプリケートされます。 初期シード処理が完了するまでにかかる時間は、データのサイズ、プライマリ データベースでのワークロードの強度、プライマリ レプリカとセカンダリ レプリカのネットワーク間のリンクの速度によって異なります。

2 つのインスタンス間のリンクの速度が必要な速度よりも遅い場合は、シードする時間が大きな影響を受けそうになります。 指定されたシード処理速度、データの合計サイズ、リンク速度を使用して、データ レプリケーションが開始されるまでの初期シード処理フェーズにかかる時間を見積もることができます。 たとえば、単一の 100 GB データベースの場合、リンクが 1 時間あたり 84 GB をプッシュできる場合や、別のリンクにシード処理されている他のデータベースがない場合、初期シード フェーズには約 1.2 時間かかります。 リンクが転送できるのが 1 時間あたり 10 GB のみの場合、100 GB のデータベースのシード処理には約 10 時間かかります。 複数のリンクを介してレプリケートするデータベースが複数ある場合、シード処理は並列で実行され、低速リンク速度と組み合わせると、初期シード処理フェーズが大幅に長くなる可能性があります。特に、すべてのデータベースからのデータの並列シード処理が使用可能なリンク帯域幅を超える場合です。

重要

初期シード処理フェーズは、非常に低速または混雑したリンクでは数日かかる場合があります。 この場合、リンクを作成するとタイムアウトする可能性があります。リンクの作成は、6 日後に自動的に取り消されます。

リンクで問題が発生した場合は、SQL Server Management Studio (SSMS)、Transact-SQL (T-SQL)、Azure PowerShell、または Azure CLI を使用して、リンクの現在の状態に関する情報を取得できます。

T-SQL を使用してリンク状態の詳細を簡単に確認してから、Azure PowerShell または Azure CLI を使用してリンクの現在の状態に関する包括的な情報を取得します。

リンクの監視は、SQL Server Management Studio (SSMS) 21.0 (プレビュー) 以降で使用できます。

SSMS でリンクの状態を確認するには、次の手順に従います。

  1. リンクをホストするレプリカに接続します。

  2. オブジェクト エクスプローラーで、[AlwaysOn 高可用性][可用性グループ] の順に展開します。

  3. リンクの名前を右クリックし、[ プロパティ ] を選択して [リンクの プロパティ ] ウィンドウを開きます。

    SSMS のリンクの右クリック メニューのスクリーンショット。プロパティが強調表示されています。

  4. [リンクのプロパティ] ウィンドウには、レプリカ情報、リンクの状態、エンドポイント証明書の有効期限など、リンクに関する有用な情報が表示されます。

    SSMS のリンク プロパティ ウィンドウのスクリーンショット。

replicaState 値は、現在のリンクを表します。 状態に Error も含まれている場合は、状態に一覧表示されている操作中にエラーが発生したことを示します。 たとえば、LinkCreationError は、リンクの作成中にエラーが発生したことを示します。

replicaState が取り得る値は次のとおりです。

  • CreatingLink: 初期シード処理
  • LinkSynchronizing: データ レプリケーションが進行中です
  • LinkFailoverInProgress: フェールオーバーが進行中です

リンク状態プロパティの完全な一覧については、「分散型可用性グループ - GET」REST API コマンドを確認します。

リンクの使用時に発生する可能性のあるエラーとして 2 種類のカテゴリがあります。リンクを初期化しようとしたときのエラーと、リンクを作成しようとしたときのエラーです。

リンクを初期化するときに次のエラーが発生する可能性があります (リンク状態: LinkInitError):

  • エラー 41962: リンクが 5 分以内に開始されなかったため、操作は中止されました。 ネットワーク接続を確認して、もう一度試してください。
  • エラー 41973: SQL Server のエンドポイント証明書が Azure SQL Managed Instance に正しくインポートされていないため、リンクを確立できません。
  • エラー 41974: SQL Managed Instance のエンドポイント証明書が SQL Server に正しくインポートされていないため、リンクを確立できません。
  • エラー 41976: 可用性グループが応答していません。 名前と構成パラメーターを確認して、もう一度やり直してください。
  • エラー 41986: 接続が失敗したか、セカンダリ レプリカが応答しないため、リンクを確立できません。 名前、構成パラメーター、ネットワーク接続を確認して、もう一度やり直してください。
  • エラー 47521: セカンダリ サーバーが要求を受信しなかったため、リンクを確立できません。 プライマリ サーバー上の可用性グループとデータベースが正常であることを確認して、もう一度やり直してください。

リンクを作成すると、次のエラーが発生する可能性があります (リンクの状態: LinkCreationError)。

  • エラー 41977: ターゲット データベースが応答しません。 リンク パラメーターを確認して、再試行してください。

  • 早期ログの切り捨て: 最初のシード処理が完了する前にトランザクション ログが切り捨てられると、次のいずれかのエラーが表示される可能性があります。

    • エラー 1408: データベース ミラーリングを有効にしたり可用性グループに参加させたりするには、データベース "%.*ls" のリモート コピーが十分に復旧されていません。
    • エラー 1412: データベース "%.*ls" のリモート コピーが、データベース ログのローカル コピーに含まれる時点にロールフォワードされていません。

    この問題を解決するには、リンクを 削除 して再作成する必要があります。
    この問題を回避するには、最初のシード処理フェーズ中にレプリケートされるデータベースのトランザクション ログ バックアップを SQL Server で一時停止します。

強制フェールオーバー後の矛盾した状態

強制フェールオーバーの後、両方のレプリカがプライマリ ロール状態になり、リンクが不整合な状態になるという、スプリットブレイン シナリオが発生する可能性があります。 これは、障害発生時にセカンダリ レプリカにフェールオーバーし、その後にプライマリ レプリカがオンラインに戻った場合に発生する可能性があります。

まず、スプリットブレイン シナリオになっていることを確認します。 このためには、SQL Server Management Studio (SSMS) または Transact-SQL (T-SQL) を使用します。

SSMS で SQL Server と SQL マネージド インスタンスの両方に接続し、オブジェクト エクスプローラーAlways On 高可用性可用性グループ ノードの下の 可用性レプリカ を展開する。 2 つの異なるレプリカが (プライマリ) と表示されている場合は、スプリットブレイン シナリオになっています。

または、SQL Server と SQL Managed Instance の両方で次の T-SQL スクリプトを実行して、レプリカのロールを確認することもできます。

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGName>'
SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states rs 
   ON ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

両方のインスタンスが プライマリリンクロール 列に表示している場合、その状況はスプリットブレインシナリオです。

スプリットブレイン状態を解決するには、まず元のプライマリであったレプリカのバックアップを作成します。 元のプライマリが SQL Server であった場合は、ログの末尾をバックアップします。 元のプライマリが SQL Managed Instance だった場合は、コピーのみの完全バックアップを作成します。 バックアップが完了したら、元のプライマリであり、現在は新しいセカンダリとなるレプリカのセカンダリ役割に分散可用性グループの役割を設定します。

たとえば、実際の障害が発生したときに、SQL Server ワークロードを Azure SQL Managed Instance に強制的にフェールオーバーさせたとします。また、引き続き SQL Managed Instance でワークロードを実行し、SQL Server でテール ログ バックアップを作成してから、次の例のように、分散型可用性グループを SQL Server 上のセカンダリ ロールに設定する予定であるとします。

--Execute on SQL Server 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] 
SET (ROLE = SECONDARY) 
GO 

次に、次の例のように、リンクを使用して、SQL Managed Instance から SQL Server への計画的な手動フェールオーバーを実行します。

--Execute on SQL Managed Instance 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER 
GO 

期限切れの証明書

リンクに使用された証明書の有効期限が切れる可能性があります。 証明書の有効期限が切れると、リンクは失敗します。 この問題を解決するには、証明書をローテーションします。

ネットワーク接続をテストする

リンクが機能するためには、SQL Server と SQL Managed Instance との間に、双方向のネットワーク接続が必要です。 SQL Server 側でポートを開き、SQL Managed Instance 側で NSG 規則を構成した後、SQL Server Management Studio (SSMS) または Transact-SQL を使用して接続をテストします。

SQL Server と SQL Managed Instance の両方で一時的な SQL Agent ジョブを作成してネットワークをテストし、2 つのインスタンス間の接続を確認します。 SSMS で Network Checker を使用すると、ジョブが自動的に作成され、テストの完了後に削除されます。 T-SQL を使用してネットワークをテストする場合は、SQL Agent ジョブを手動で削除する必要があります。

SQL Server on Linux 上の SQL Server エージェントによる PowerShell スクリプトの実行は現在サポートされていないため、現在、SQL Server on Linux 上の SQL Server エージェント ジョブから Test-NetConnection を実行することはできません。

SQL Agent を使用してネットワーク接続をテストするには、次の要件が必要です。

  • テストを実行するユーザーは、SQL Server と SQL Managed Instance の両方でジョブ を作成するために、権限(sysadmin として、または の SQLAgentOperator ロールに属する)が必要です。
  • SQL Server エージェント サービスが、SQL Server 上で実行している必要があります。 SQL Managed Instance ではエージェントが既定で有効であるため、追加の措置は必要ありません。

SSMS で SQL Server と SQL Managed Instance 間のネットワーク接続をテストするには、次の手順を実行します。

  1. SSMS でプライマリ レプリカとなるインスタンスに接続します。

  2. オブジェクト エクスプローラーでデータベースを展開し、セカンダリにリンクするデータベースを右クリックします。 [タスク]>[Azure SQL Managed Instance リンク]>[接続のテスト] を選択して、ネットワーク チェッカー ウィザードを開きます。

    S S M S のオブジェクト エクスプローラーのスクリーンショット。データベース リンクの右クリック メニューで [接続のテスト] が選択されています。

  3. ネットワーク チェッカー ウィザードの [概要] ページで [次へ] を選びます。

  4. [前提条件] ページのすべての要件が満たされている場合は、[次へ] を選択します。 それ以外の場合は、満たされていない前提条件を解決した後、検証を再実行を選択します。

  5. [ログイン] ページで、[ログイン] を選択して、セカンダリレプリカとなる他のインスタンスに接続します。 を選択し、次にを選択します。

  6. [ネットワーク オプションの指定] ページで詳細を確認し、必要に応じて IP アドレスを指定します。 を選択し、次にを選択します。

  7. [の概要] ページでウィザードが実行する操作を確認し、[完了] を選択して、2 つのレプリカ間の接続をテストします。

  8. 結果 ページを確認して、2つのレプリカ間に接続が存在することを確認した後、[閉じる] を選択して完了します。

注意

次の手順に進むのは、ソース環境とターゲット環境の間のネットワーク接続を検証済みの場合だけにしてください。 それ以外の場合は、進める前に、ネットワーク接続の問題のトラブルシューティングを行ってください。

リンク機能の詳細については、以下のリソースを参照してください。