AlwaysOn 環境での自動フェールオーバー SQL Serverトラブルシューティング

この記事では、自動フェールオーバー中に発生する問題の解決に役立SQL Server。

元の製品バージョン:  SQL Server
元の KB 番号:   2833707

概要

Microsoft SQL ServerAlwaysOn 可用性グループは、自動フェールオーバー用に構成できます。 したがって、プライマリ レプリカをホストしている SQL Server のインスタンスで正常性の問題が検出された場合、プライマリ ロールを自動フェールオーバー パートナー (セカンダリ レプリカ) に移行できます。 ただし、セカンダリ レプリカを常にプライマリ ロールに移行することはできません。代わりに解決役割にのみ移行されます。 プライマリ レプリカが正常な状態に戻らない限り、プライマリ ロールにはレプリカはありません。 さらに、可用性データベースにアクセスできません。

この記事では、自動フェールオーバーが失敗した一般的な原因の一覧を示します。 さらに、この記事では、これらのエラーの原因を診断するために実行できる手順について説明します。

自動フェールオーバーが正常にトリガーされる場合の現象

プライマリ レプリカをホストしている SQL Server のインスタンスで自動フェールオーバーがトリガーされると、セカンダリ レプリカは解決役割に移行し、次にプライマリ ロールに移行します。 さらに、次のようなエラー メッセージSQL Serverログ レポートに表示されます。

可用性グループ ' ' のローカル可用性レプリカの状態が 'RESOLVING_NORMAL' から <Group name> 'PRIMARY_PENDING' に変更されました
可用性グループ ' ' のローカル可用性レプリカの状態が 'PRIMARY_PENDING' から <Group name> 'PRIMARY_NORMAL' に変更されました

エラー ログ

注意

セカンダリ レプリカは、セカンダリ レプリカの状態から RESOLVING_NORMAL状態に 正常 PRIMARY_NORMAL されます。

自動フェールオーバーが失敗した場合の現象

自動フェールオーバー イベントが成功しなかった場合、セカンダリ レプリカはプライマリ ロールに正常に移行しません。 したがって、可用性レプリカは、このレプリカが解決状態にあると報告します。 さらに、可用性データベースは[同期しない] 状態であり、アプリケーションはこれらのデータベースにアクセスできないことを報告します。

たとえば、次の図では、SQL Server Management Studio は、自動フェールオーバー プロセスでセカンダリ レプリカをプライマリ ロールに移行できなかったため、セカンダリ レプリカが [解決] 状態にあると報告します。

可用性レプリカ

この記事では、自動フェールオーバーが成功しない可能性があるいくつかの理由と、各原因を診断する方法について説明します。

ケース 1: "指定した期間の最大エラー数" の値が使い果たされる

可用性グループには、Windows期間プロパティの [最大エラー数] などのクラスター リソース プロパティがあります。 このプロパティは、複数のノード障害が発生した場合にクラスター化されたリソースが無期限に移動しないようにするために使用されます。

フェールオーバーが失敗した原因かどうかを調査および診断するには、Windows クラスター ログ (Cluster.log) を確認し、プロパティを確認します。 これを行うには、次の手順を実行します。

  • 手順 1: クラスター ログ内のデータWindows確認する (Cluster.log)

    1. プライマリ Windows PowerShellホストしているクラスター ノードWindowsクラスター ログを生成するには、次のコマンドを使用します。 これを行うには、プライマリ レプリカをホストしているサーバー サーバーのインスタンス上の昇格された PowerShell ウィンドウでSQL Serverコマンドレットを実行します。

      Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
      

      Windows PowerShell

      注意

      • この手順の -TimeSpan 15 パラメーターは、前の 15 分間に問題が発生したと仮定して使用されます。
      • 既定では、ログ ファイルは %WINDIR%\cluster\reports に作成されます。
    2. クラスター ログを確認するには、メモ帳で Cluster.log ファイルWindows開きます。

    3. [編集] をメモ帳し、[検索]をクリックし、ファイルの最後にある文字列 "failoverCount" を検索します。 結果を確認すると、次のようなメッセージが表示されます。

      グループをフェールオーバーしない <Resource name> 、failoverCount 3、failoverThresholdSetting <Number> 、computedFailoverThreshold 2

      クラスター メモ帳

  • 手順 2: [指定した期間] プロパティの [最大エラー数] を確認する

    1. フェールオーバー クラスター マネージャーを開始します。

    2. ナビゲーション ウィンドウで、[役割] を クリックします

    3. [役割 ] ウィンドウで 、クラスター化されたリソースを右クリックし、[プロパティ] を クリックします

    4. [フェールオーバー] タブを クリックし、[指定した期間] の値で [最大エラー数] を確認 します。

      指定した期間の最大エラー数

      注意

      既定の動作では、クラスター化されたリソースが 6 時間で 3 回失敗した場合、失敗した状態を維持する必要があります。 可用性グループの場合、レプリカは解決状態に残ります。

まとめ

ログを分析すると 、failoverCount 値 3 が computedFailoverThreshold 値 2 より大きい場合があります。 したがって、Windowsは、可用性グループ リソースのフェールオーバー 操作をフェールオーバー パートナーに完了できません。

解決方法

この問題を解決するには、指定した 期間の値で最大エラー数を増や します。

注意

この値を大きくすると、問題が解決しない可能性があります。 可用性グループが短時間で何度も失敗するより重大な問題が発生する可能性があります (既定では 15 分)。 この値を大きくすると、可用性グループが失敗した状態に残る前に失敗する回数が増える場合があります。 自動フェールオーバーが発生し続ける理由を特定するために、積極的なトラブルシューティング作業をお勧めします。

ケース 2: NT Authority\SYSTEM アカウントのアクセス許可が不十分

リソース DLL SQL Server データベース エンジンは、ODBC を使用してSQL Serverをホストしているリソース DLL のインスタンスに接続します。 この接続に使用されるログオン資格情報は、NT AUTHORITY\SYSTEM ログイン SQL Serverローカル アカウントです。 既定では、このローカル ログイン アカウントには次のアクセス許可が付与されます。

  • 可用性グループの変更
  • SQL の接続
  • サーバー状態の表示

NT AUTHORITY\SYSTEM ログイン アカウントに自動フェールオーバー パートナー (セカンダリ レプリカ) に対するこれらのアクセス許可がない場合、自動フェールオーバーが発生した場合、SQL Server は正常性検出を開始できません。 したがって、セカンダリ レプリカはプライマリ ロールに移行できません。 これが原因であるかどうかを調査して診断するには、クラスター ログのWindows確認します。 これを行うには、次の手順を実行します。

  1. このWindows PowerShell使用して、クラスター ノードWindowsクラスター ログを生成します。 これを行うには、プライマリ ロールに移行しなかったセカンダリ レプリカをホストしている SQL Server のインスタンスの昇格された PowerShell ウィンドウで次のコマンドレットを実行します。

    Get-ClusterLog -Node <SQL Server node name> -TimeSpan 15
    

    PowerShell ウィンドウ

  2. クラスター ログを確認するには、メモ帳で Cluster.log ファイルWindows開きます。

  3. 次のようなエラー メッセージが表示されます。

    診断コマンドの実行に失敗しました。 ユーザーには、このアクションを実行するアクセス許可はありません。

    エラー メッセージ

まとめ

Cluster.log ファイルは、診断コマンドを実行するときにアクセス許可のSQL Server報告します。 この例では、自動フェールオーバー ペアのセカンダリ レプリカをホストしている SQL Server のインスタンスの NT AUTHORITY\SYSTEM ログイン アカウントからサーバー状態の表示アクセス許可を削除することで、このエラーが発生しました。

解決方法

この問題を解決するには、NT AUTHORITY\SYSTEM ログイン アカウントに十分なアクセス許可を付与して、リソース DLL の正常性SQL Server データベース エンジンします。

ケース 3: 可用性データベースが SYNCHRONIZED 状態ではない

自動的にフェールオーバーするには、可用性グループで定義されている可用性データベースはすべて、プライマリ レプリカとセカンダリ レプリカの間で SYNCHRONIZED 状態である必要があります。 自動フェールオーバーが発生した場合、この同期条件を満たして、データ損失が発生しなかからなかっている必要があります。 したがって、可用性グループ内の 1 つの可用性データベースが同期状態または同期されていない状態の場合、自動フェールオーバーはセカンダリ レプリカをプライマリ ロールに正常に移行しません。

自動フェールオーバーに必要な条件の詳細については、「自動フェールオーバーに必要な条件」セクションと「同期コミットレプリカ」の「フェールオーバーモードとフェールオーバー モード(Always On Availability Groups)」の 2 つの設定セクションをサポートしています。

フェールオーバーが失敗した原因かどうかを調査および診断するには、エラー ログのSQL Serverしてください。 次のようなエラー メッセージが表示されます。

1 つ以上のデータベースが同期されていないか、可用性グループに参加していない

ERRORLOG メモ帳 イメージ

可用性データベースが SYNCHRONIZED 状態であるかどうかを確認するには、次の手順を実行します。

  1. Connectレプリカにコピーします。

  2. 次の SQLスクリプトを実行して、フェールオーバーしなかった可用性グループ内のすべての可用性データベースの値 is_failover_ready を確認します。

    注意

    可用性データベースの値を 0 に設定すると、自動フェールオーバーを防止できます。この値は、可用性データベースが SYNCHRONIZED でなかっていたかどうかを示します。

    Select database_name, is_failover_ready from sys.dm_hadr_database_replica_cluster_states where replica_id in (select replica_id from sys.dm_hadr_availability_replica_states)
    

    クエリ イメージ

まとめ

可用性グループの自動フェールオーバーが成功するには、すべての可用性データベースが状態にある必要 SYNCHRONIZED があります。 可用性モードの詳細については、次のリンクを参照してください。

AlwaysOn 可用性グループの可用性モード

ケース 4: フェールオーバーできない、クライアント プロトコルに対して 'Force Protocol Encryption' 構成が選択されている

この構成を確認するには、次の方法を実行します。

  1. 起動SQL Server 構成マネージャー。
  2. 左側 のウィンドウ、[11.0 構成] SQL Native Clientを右クリックし、[プロパティ] を選択 します
  3. ダイアログ チェックの [強制的な暗号化] を [はい] に 設定した場合 は、[いいえ] に 変更します
  4. フェールオーバーの再テスト。

sql config

まとめ

SQL ServerAlwaysOn 正常性監視では、ローカル ODBC 接続を使用して、正常性SQL Server監視します。 SQL Server 自体が S QL Server ネットワーク構成セクションの SQL Server 構成マネージャー で強制的に暗号化するように構成されている場合は、SQL Server 構成マネージャー の [クライアント構成] セクションでのみ強制的なプロトコル暗号化を有効にする必要があります。 詳細については、「暗号化された接続を有効にする」を参照データベース エンジン。