次の方法で共有


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

適用対象: Azure SQL Managed Instance の

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

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

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

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

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

T-SQL を使用して、シード処理フェーズ中、またはデータ同期の開始後にリンクの状態を確認します。

次の T-SQL クエリを使用して、リンクを介してシード処理されたデータベースをホストする SQL Server または SQL Managed Instance のシードフェーズ中にリンクの状態を確認します。

SELECT
    ag.local_database_name AS 'Local database name',
    ar.current_state AS 'Current state',
    ar.is_source AS 'Is source',
    ag.internal_state_desc AS 'Internal state desc',
    ag.database_size_bytes / 1024 / 1024 AS 'Database size MB',
    ag.transferred_size_bytes / 1024 / 1024 AS 'Transferred MB',
    ag.transfer_rate_bytes_per_second / 1024 / 1024 AS 'Transfer rate MB/s',
    ag.total_disk_io_wait_time_ms / 1000 AS 'Total Disk IO wait (sec)',
    ag.total_network_wait_time_ms / 1000 AS 'Total Network wait (sec)',
    ag.is_compression_enabled AS 'Compression',
    ag.start_time_utc AS 'Start time UTC',
    ag.estimate_time_complete_utc as 'Estimated time complete UTC',
    ar.completion_time AS 'Completion time',
    ar.number_of_attempts AS 'Attempt No'
FROM sys.dm_hadr_physical_seeding_stats AS ag
    INNER JOIN sys.dm_hadr_automatic_seeding AS ar
    ON local_physical_seeding_id = operation_id

-- Estimated seeding completion time
SELECT DISTINCT CONVERT(VARCHAR(8), DATEADD(SECOND, DATEDIFF(SECOND, start_time_utc, estimate_time_complete_utc) ,0), 108) as 'Estimated complete time'
FROM sys.dm_hadr_physical_seeding_stats

クエリから結果が返されない場合、シード処理プロセスは開始されていないか、既に完了しています。

プライマリ インスタンスで次の T-SQL クエリを使用して、データ同期が開始されたらリンクの正常性を確認します。

DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   rs.synchronization_health_desc [Link sync health]
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 0 AND rs.role = 2 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

このクエリは、次の可能な値を返します。

  • 結果なし: セカンダリ インスタンスでクエリが実行されました。
  • HEALTHY: リンクは正常であり、レプリカ間でデータが同期されています。
  • NOT_HEALTHY: リンクが異常であり、レプリカ間でデータが同期されていません。

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: ターゲット データベースが応答していません。 リンク パラメーターを確認し、もう一度やり直してください。

強制フェールオーバー後の一貫性のない状態

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

まず、スプリット ブレイン シナリオであることを確認します。 これを行うには、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 エージェント ジョブを作成して、2 つのインスタンス間の接続を確認することで、ネットワークをテストします。 SSMS で ネットワーク チェッカー を使用すると、ジョブが自動的に作成され、テストの完了後に削除されます。 T-SQL を使用してネットワークをテストする場合は、SQL エージェント ジョブを手動で削除する必要があります。

手記

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

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

  • テストを実行するユーザーは、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つのレプリカ間に接続が存在することを確認した後、[閉じる] を選択して完了します。

注意

ソース環境とターゲット環境の間のネットワーク接続を検証した場合にのみ、次の手順に進みます。 それ以外の場合は、先に進む前にネットワーク接続の問題のトラブルシューティングを行います。

リンク機能の詳細については、次のリソースを確認してください。