web-dev-qa-db-ja.com

AlwaysOn可用性グループの自動フェールオーバーが機能しない

AGセットアップで遊ぶ私はWSFCを起動し、DevClusterOnlineと呼ばれる1つの可用性グループの2つのノードで構成しています。両方のノード（DEV-AWEB5プライマリ、DEV-AWEB6セカンダリ）はWindows Server 2008 R2を実行しています。

AGの状態をチェックすると、次のようになります。

Availability Group Health description

以下のクエリを実行すると、この結果セットが返されます。 Synchronous commit and automatic failover setup

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

DEV-AWEB5を切断すると、グループリスナー（DevListener）に接続できなくなりますが、pingを実行すると、pingに応答します。レプリカ-DEV-AWEB6がRESOLVING状態になり、DBにアクセスできません。ただし、Management Studioに手動で移動してFailoverをDEV-AWEB6に設定すると、再び稼働状態になり、DevListenerがもう一度接続を受け入れます。

これらの事実がフェイルオーバーが実際に機能していることを確認していること、コミットを同期して自動フェイルオーバーを構成していることを考えると、セットアップで誤動作しているかどうかはわかりません。

DEV-AWEB5を切断すると、レプリカが接続を保持し、したがってDevListenerも保持されることを期待します。自動フェイルオーバーにより、AGリスナーに透過的に接続できると思います。エンドユーザーの観点から見ると、Webシステムを使用している場合、DBサーバーの1つがダウンしたことは気付かないはずです。

私はここで立ち往生しています、誰かが私が間違っていることを教えてくれますか？

sql-serversql-server-2012availability-groups
10
Marcus

DEV-AWEB5を切断した場合

必要に応じて、「切断」を定義します。私の推測では、あなたは箱を上げたままSQL Serverをダウンさせたのでしょう。

グループリスナー（DevListener）に接続できませんが、pingを実行すると、pingに応答します

これは、リスナーが、表されている可用性グループのWSFCクラスターリソースグループ内の単なる仮想ネットワーク名（VNN）であるためです。 DEV_AWEB5ノードはまだクラスターリソースグループを所有していますが、ほとんどの場合、障害状態にあるのはAGクラスターリソースです。 VNNはまだオンラインである必要があります（予想される動作）。そのリソースグループ（この場合はDEV-AWEB5）を所有しているノードを指しているだけです。実際、PowerShellリモート処理を有効にしていて、以下を実行した場合：

Invoke-Command -ComputerName "YourListenerName" -ScriptBlock { $env:computername }

同様に、DEV-AWEB5にRDPできる場合（機能やアクセシビリティなどがある場合）、リスナー名（mstsc /v:YourListenerName）を使用してRDPを実行できます。それは単なるVNNです。

その戻り値は、所有ノードのコンピューター名です。

すべての症状から、フェイルオーバーのしきい値に達したことは間違いありません。フェイルオーバーしきい値は、指定した期間内にクラスターがリソースグループのフェイルオーバーを試行する回数を決定します。これらの値のデフォルトの最大フェイルオーバーn-1（wherenは6時間の期間のノード数です。これは、次のWSFC PowerShellコマンドで確認できます。

Get-ClusterGroup -Name "YourAgName" |
    Select-Object Name, FailoverThreshold, FailoverPeriod

これは設定を提供するだけです（もちろん、必要に応じて変更できます）。

これが当てはまることを証明する最良の方法は、クラスターログを生成する必要があることです（システムイベントログは、「障害が発生した」などの詳細のみを記録します）。

Get-ClusterLog -Node "YourClusterNode" -TimeSpan <amount_of_minutes_since_failure>

それはデフォルトで「C：\ Windows\Cluster\Reports」フォルダに入れられ、ファイルは「Cluster.log」と呼ばれます。

そのクラスターログを開くと、何が起こったのか、なぜ起こったのかを正確に示す次の文字列を見つけることができるはずです。

グループをフェイルオーバーしない[YourClusterGroupName]、failoverCount [フェイルオーバーの数]、フェイルオーバーのしきい値[フェイルオーバーのしきい値]、nodeAvailCount [ノード使用可能カウント]。

上記のメッセージは、WSFCが発生しすぎたためにグループをフェイルオーバーしないことを通知しているだけです（しきい値に達したため）。

なぜこれが起こるのですか？単に、ノード間で頻繁に行き来するクラスターリソースのピンポン効果を防ぐためです。

これは、フェイルオーバーテストでこれらのしきい値に達することは一般的ですが、本番環境では通常、調査する必要がある問題を示します。

6
Thomas Stringer

MSSQLを汎用サービスリソースとして追加することは、答えではありません。

これで、クラスターマネージャーがSQL Serverサービスを管理するようになります。そうです、はい、自動的にフェールオーバーしますが、SQL Server構成マネージャーで、サービスが「手動」に設定され、クラスターマネージャーがこれで、SQLサーバーサービスを制御できます。

Cluster Managerを非クラスター化アプリケーションの管理に任せています。

それは涙で終わります。

MSのドキュメントに従って、SQL Server可用性グループを正しく構成するための正しいアプローチ。

また、クラスターマネージャー>役割>フェイルオーバータブで定義されているフェイルオーバーパラメーターを超えていないことを確認してください。

これらの制限を超えている場合、クラスターはリソースをフェイルオーバーせず、エラーがアプリケーションイベントログに記録されます。

1
Keiran Grogan