SQL Serverがセカンダリノードにフェイルオーバーするのに1時間かかる
私は新しい仕事をしています。2008R2（SP1） [〜＃〜] wsfc [〜＃〜] があり、SQL Server 2008 FCIをホストしています。
各ノードには独自のストレージがあり、ノードは32コアで32 GBのメモリを備えています（このように構成されている理由を聞かないでください）。各ノードのストレージは、ノードがセカンダリの場合は読み取り専用コピーです。今日まで、それは共有ストレージであると言われました。クォーラムにはディスク共有監視ではなくファイル共有監視があるため、システム管理者と話しました。次に、各サイトに独自のストレージがあるが、セカンダリノードではアクティブではないことを説明しました。データのブロックは、プライマリノードとセカンダリノードの間で複製されます。
何が起こっているのかは、ホストがフェイルオーバーしていることです（理由は不明）。最も可能性の高い原因は、ハートビートタイムアウトです。
ノードがシャットダウンコマンドを送信したSQLログをフェイルオーバーするとき。
2番目の（SQL）ノードが1分ほどで起動する場合があります。
それ以外の場合、SQL Serverがセカンダリノードでオンラインになるのに1時間かかります。 OS側では、フェイルオーバーは迅速で、SQL Serverだけで時間がかかります。
私の考えは、何かが走っていたということです。
このようなことを示すログは見つかりませんでした。
この反応状態では、システムDBログやテーブルなど、SQL内で確認できるものはありますか（シャットダウンコマンドの発行後、他のインスタンスがオンラインになるまでエラーログには何もありません）？
私はこれまでこの問題に遭遇したことがなく、Googleに無益な努力を払っています。
最初に、いくつかのことを説明します。
各ノードには独自のストレージがあり、ノードは32コアで32 GBのメモリを備えています（このように構成されている理由を聞かないでください）。各ノードのストレージは、ノードがセカンダリの場合は読み取り専用コピーです。今日まで、それは共有ストレージであると言われました。 ...次に、各サイトに独自のストレージがあるが、セカンダリノードではアクティブではないことを説明しました。データのブロックは、プライマリノードとセカンダリノードの間で複製されます。
これはブロック複製ストレージであり、どのように、または何を行っているのかはわかりません。ソフトウェアを介して行うことも、ハードウェアを介して行うことも、両方を組み合わせることもできます。
クォーラムにはディスク共有監視ではなくファイル共有監視があるため、システム管理者と話しました。
FSWを使用しても問題はありません。また、最も一般的な証人タイプでもあります。
今方法論へ：
何が起こっているのかは、ホストがフェイルオーバーしていることです（理由は不明）。最も可能性の高い原因は、ハートビートタイムアウトです。
クラスタログに理由が表示されます。フェールオーバーが発生した理由を理解するために、クラスターログを生成して調べます。たとえば、根本的な原因がハートビートの失敗である場合、ハートビートが失敗した理由を理解するために、各ノードで追加のパケットロギングが必要になります。
ノードがシャットダウンコマンドを送信したSQLログをフェイルオーバーするとき。
はい、SQL Serverのエラーログでこれが示された時間を知っています。したがって、この問題はこの前にクラスタログで発生する必要がありました。これにより、イベントのタイムラインが開始され、SQL Serverが起動するまでの全体的な時間に最終的につながるはずです。
2番目の（SQL）ノードが1分ほどで起動する場合があります。
定義する必要があります。
SQL Serverサービスがクラスターによって開始されようとしたのか、ユーザークエリのためにオンラインでアクセス可能にしたいデータベースがオンラインでアクセス可能であるのかは、あいまいです。どちらのことを言っているのかわかりません。
どちらの場合も、SQL Serverリソースをオンライン（サービス）にするのがクラスターの場合は、リソースグループを現在所有しているノードのクラスターログにすべて含まれています。ログで名前をすばやく検索できるため、リソースへのオンライン呼び出しを見つけるのは簡単です。データベースにアクセスできるようにする場合は、SQL Serverのエラーログを調べて、起動メッセージと回復メッセージにかかった時間を確認できます。どちらも取るに足らないもので、イベントと時間のタイムラインに追加できます。
それ以外の場合、SQL Serverがセカンダリノードでオンラインになるのに1時間かかります。 OS側では、フェイルオーバーは迅速で、SQL Serverだけで時間がかかります。
繰り返しますが、「OS側」の意味がわかりません。リソースをオンラインにする呼び出しは成功し、SQL Serverは起動しますが、データベースにアクセスできないか、リソースグループが移動しますが、リソースはタイムリーに起動しませんか？
このようなことを示すログは見つかりませんでした。
AFAIKには、データベースの起動に長い時間がかかった理由を示すログがありません。イベントのタイムラインを作成し、複数のソースからデータを抽出して、そのタイムラインを構築する必要があります。次に、何が起こったか、各ステップにかかる時間についてまとめることができます。あなたは長いステップに集中して、それらを個々のピースに分解することができます。
たとえば、これらのイベントに対してRCAを実行すると、次のように始まります。
- 元の問題が発生したのはいつで、それは何でしたか？
- SQL Serverはいつ影響を受け、どのように影響を受けましたか？フェイルオーバーがあったとしましょう。
- 以前の所有ノードでフェイルオーバーが発生したのはいつですか？
- リソースグループが次の所有ノードに移動したのはいつですか（最後に所有していない場合）。
- SQL Serverリソースをオンラインにする呼び出しが最初に成功したのはいつで、その前に失敗した試みはありましたか？
- SQL Serverはいつサービスを開始しましたか？
- データベースはどの順序で開始されましたか？
- 各データベースが回復フェーズを終了したのはいつで、どのくらい時間がかかりましたか？
- ユーザー接続が最初に成功したのはいつですか？
- ログに他の注目すべきエラー、警告、または情報メッセージがありましたか？
全体的なタイムラインが得られたら、最も時間がかかった部分を見つけ、そこからさらに調査することができます。