この記事では、Always on Availability Groupサイトを作成、構成、または保守する際に直面する可能性のあるいくつかの問題について説明します。
この記事を読む前に、前の記事「SQLServerでのAlwayson可用性グループの設定と構成」を読んで、この記事に示されているAlwayson可用性グループの概念と新しい可用性グループウィザードについて理解することをお勧めします。
常に可用性グループ機能が有効になっていません
SQL Server Management Studioのオブジェクトエクスプローラーで、Always OnHighAvailabilityノードから新しいAlwaysonAvailabilityグループを作成しようとしたときに、次のエラーメッセージが表示されたとします。
このインスタンスで可用性グループを作成する前に、サーバーインスタンス「SQL1」に対してAlwaysOn可用性グループ機能を有効にする必要があります。この機能を有効にするには、SQL Server構成マネージャーを開き、[SQL Serverサービス]を選択し、SQL Serverサービス名を右クリックして、[プロパティ]を選択し、[サーバーのプロパティ]ダイアログの[常にオンの可用性グループ]タブを使用します。常時接続の可用性グループを有効にするには、サーバーインスタンスがWindows Serverフェールオーバークラスター（WSFC）ノードによってホストされている必要がある場合があります。 （Microsoft.SqlServer.Management.HadrTasks）
エラーメッセージから明らかなように、AlwaysOn可用性グループ機能は、Alwayson可用性グループサイトに参加する各SQLServerインスタンスで、そのサイトを作成する前に有効にする必要があります。
SQL Server Configuration Managerコンソールを開き、[SQL Serverサービス]タブを参照して、SQL Serverデータベースエンジンサービスを右クリックし、[プロパティ]オプションを選択することで、Always onAvailabilityGroup機能を簡単に有効にできます。
開いたSQLServerの[プロパティ]ウィンドウから、[常に高可用性をオンにする]タブに移動し、[常にオンの可用性グループを有効にする]の横にあるチェックボックスをオンにします。 、以下に示すように、この変更を有効にするにはSQLServerサービスを再起動する必要があることを考慮に入れてください。
データベースの前提条件の検証の問題
新規可用性グループウィザードの前の手順で、AlwaysonAvailabilityグループに参加するデータベースを指定するように求められます。データベースを追加する前に、データベースは前提条件の検証チェックに合格する必要があります。そうしないと、以下のエラーメッセージに示すように、データベースリストからデータベースを選択できません。
可用性グループに追加するには、このデータベースを完全復旧モデルに設定する必要があります。 Recovery ModelデータベースプロパティをFullに設定し、データベースに対してデータベースの完全バックアップまたは差分バックアップを実行します。次に、データベースでログのバックアップをスケジュールする必要があります。
メッセージは明確です。データベースを完全復旧モデルで構成し、そのデータベースで完全バックアップまたは差分バックアップを実行する必要がある場合。
また、ウィザードは、リカバリモデルをFullに変更した後、そのデータベースのトランザクションログバックアップをスケジュールするように警告します。これにより、トランザクションログファイルが自動的に切り捨てられ、そのトランザクションログファイルが空き領域から実行されなくなります。
この問題を修正するには、データベースのプロパティウィンドウの[オプション]タブでデータベースリカバリモデルを[シンプル]から[フル]に変更し、次に示すように、そのデータベースからフルバックアップを作成します。
[データベースの選択]ウィンドウを更新すると、以下に示すように、データベースのステータスが[前提条件を満たしている]に変更されます。
共有ネットワークロケーション許可の問題
Always on Availability Groupサイトを構成しようとしたときに、新しい可用性グループウィザードの検証手順が失敗し、次のエラーメッセージが表示されました。
プライマリサーバー「SQL1」は「\\SQL1\ AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak」に書き込むことができません。 （Microsoft.SqlServer.Management.HadrModel）
サーバー'SQL1'のバックアップに失敗しました。 （Microsoft.SqlServer.SmoExtended）
バックアップデバイス'\\SQL1 \ AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak'を開くことができません。オペレーティングシステムエラー5（アクセスが拒否されました。）
BACKUPDATABASEが異常終了しています。 （.Net SqlClientデータプロバイダー）
フルデータベースとログバックアップの初期同期方法では、フルバックアップファイルとトランザクションログバックアップファイルを一時的に保持してすべてのセカンダリレプリカに復元するために、共有フォルダーが必要です。プライマリレプリカがバックアップファイルを書き込めない場合、またはセカンダリレプリカがバックアップファイルを読み取ることができない場合、新しい可用性グループの検証プロセスは次のように失敗します。
この問題を修正するには、プライマリレプリカとセカンダリレプリカのSQL Serverサービスアカウントに、エラーメッセージに表示されている共有フォルダーに対する読み取りと書き込みのアクセス許可を付与してから、検証プロセスを再実行して、すべてのチェックが成功したことを確認する必要があります。 、以下に示すように：
Windowsフェールオーバークラスターの問題
既存のAlwaysonAvailability Groupサイトのステータスを確認していると仮定し、次のことを確認します。
- プライマリロールがSQL1インスタンスからSQL2に移動されました。
- SQL2では、データベースは同期状態です。
- SQL1では、データベースは同期されません。
- SQL1は解決中の状態です。
以下のSSMSオブジェクトエクスプローラーからはっきりとわかるように：
問題のあるノードのSQLServerエラーログを確認すると、以下のエラーに示すように、可用性グループレプリカがオフラインになり、WindowsServerフェールオーバークラスターの問題のために可用性グループが機能しなくなったことがわかります。
- 常に可用性グループ：ローカルWindowsServerフェールオーバークラスタリングノードはオンラインではなくなりました 。これは情報メッセージです。ユーザーの操作は必要ありません。
- 常にオン：ローカルのWindows Serverフェールオーバークラスタリング（WSFC）ノードがクォーラムを失ったため、可用性レプリカマネージャーがオフラインになります。これは情報メッセージです。ユーザーの操作は必要ありません。
- 常にオン：可用性グループ「DemoGroup」のローカルレプリカが停止しています。これは情報メッセージです。ユーザーの操作は必要ありません。
同じことがWindowsServerイベントビューアからも検出できます。これは、レプリカがどのように状態を解決状態に変更するかを次のように徐々に示します。
- 常にオン：可用性グループ「DemoGroup」のローカルレプリカが解決の役割に移行する準備をしています 。これは情報メッセージです。ユーザーの操作は必要ありません。
- 可用性グループ'DemoGroup'は、可用性グループがオフラインになるため、リースの更新を停止するように求められています 。これは情報メッセージです。ユーザーの操作は必要ありません。
- 可用性グループ「DemoGroup」のローカル可用性レプリカの状態が「PRIMARY_NORMAL」から「RESOLVING_NORMAL」に変更されました。 可用性グループがオフラインになるため、状態が変更されました。関連付けられた可用性グループが削除されたか、ユーザーがWindows Serverフェールオーバークラスタリング（WSFC）管理コンソールで関連付けられた可用性グループをオフラインにしたか、可用性グループが別のSQL Serverインスタンスにフェイルオーバーしているため、レプリカがオフラインになります。詳細については、SQLServerエラーログまたはクラスターログを参照してください。これがWindowsServerフェールオーバークラスタリング（WSFC）可用性グループの場合は、WSFC管理コンソールも表示されます。
Windowsクラスターサイトのステータスを確認するには、フェールオーバークラスターマネージャーを使用して、Windowsクラスターのどの部分に障害が発生しているかを確認します。
ただし、フェールオーバークラスターマネージャーは、以下に示すように、クラスター全体がダウンしていることを示しています。
ここでWindowsフェールオーバークラスター側から最初に検証するのはクラスターサービスです。これは、以下のように、Windowsサービスコンソールから確認できます。
サービスコンソールから、ClusterServiceが実行されていないことがわかります。この問題を修正するには、そのコンソールからサービスを開始してから、フェールオーバークラスターマネージャーコンソールを更新して、以下に示すように、Windowsクラスターサイトが稼働していることを確認します。
以下に示すように、Always on Availability Groupを再度確認すると、データベースが再び同期され、Always onAvailabilityGroupサイトが再び正常な状態になっていることがわかります。
トランザクションログファイルがプライマリ側でいっぱいです
Always on可用性グループデータベースの1つで新しいクエリを実行しようとすると、次のエラーメッセージが表示されると想定します。
トランザクションログファイルをブロックしているものと切り捨てられないものを確認すると、次のように、このデータベースのトランザクションログファイルがログバックアップ操作の切り捨てを保留していることがわかります。
次のように、トランザクションログバックアップジョブのスケジュールを忘れた場合に備えて、そのデータベースのトランザクションログバックアップを作成します。
そして、そのデータベースのトランザクションログをブロックしているものをもう一度確認します。私のシナリオでは、Availability_Replicaを待機していることが示されています。つまり、ログはセカンダリレプリカへの書き込みを待機していますが、Always on Availability Groupサイトの問題により、以下のように、これらのトランザクションログをセカンダリレプリカに送信できません。
Always on Availability Groupサイトを確認およびトラブルシューティングするのに最適な場所は、Always on Dashboardです。これは、Availability Group名を右クリックし、[ShowDashboard]オプションを選択して開くことができます。
ダッシュボードから、以下に示すように、接続の問題により、セカンダリレプリカSQL2がプライマリレプリカと同期されていないことがわかります。
次のように、セカンダリレプリカをチェックし、SQLServerサービスがセカンダリ側で稼働していることを確認します。
次に、Availability Groupダッシュボードを再度更新すると、Always onAvailabilityGroupサイトが再び正常になっていることがわかります。トランザクションログファイルが何らかの操作によってブロックされているかどうかを確認すると、OLDEST_PAGEが保留中であることがわかります。これは、データベースの最も古いページがチェックポイントLSNよりも古いことを示しています。この問題は、別のトランザクションログのバックアップを取ることで簡単に修正でき、トランザクションログファイルは、以下に明確に示すように、何もブロックされません。
常に可用性グループのフェイルオーバーの設定ミス
計画外の問題が原因でプライマリレプリカがオフラインになったと想定します。予想どおり、自動フェイルオーバー操作が実行され、セカンダリレプリカが新しいプライマリレプリカとして機能するため、システムは影響を受けません。
しかし、私たちの場合、この幸せなシナリオは有効ではありません。セカンダリレプリカが解決状態に変わり、システムがダウンしています！
セカンダリレプリカのエラーログをチェックし、それが期待どおりに新しいプライマリとして機能しない理由を確認すると、以下に示すように、役割の同期の問題が原因で失敗していることがわかります。
可用性グループデータベース「AdventureWorks2017」は、役割の同期のためにミラーリングセッションまたは可用性グループがフェイルオーバーしたため、役割を「SECONDARY」から「RESOLVING」に変更しています。これは情報メッセージです。ユーザーの操作は必要ありません。
これは、この可用性グループで使用されている同期モードに問題があることを意味します。使用される同期モードは、Always onAvailabilityGroupのプロパティページから確認できます。
以下のプロパティページから、この可用性グループのフェールオーバーモードが手動でのみ実行されるように構成されていることがわかります。この場合、サーバーを再起動またはシャットダウンする前に、手動でフェイルオーバー操作を実行する必要があります。
これは、フェイルオーバーモードを自動に変更することで簡単に修正できます。この場合、計画外のシャットダウンまたは再起動が発生した場合に自動フェイルオーバー操作が実行されます。
Windowsフェールオーバークラスタークォーラムが偶数のレプリカに対してノードマジョリティで構成されている場合にも同じ問題が発生する可能性があり、サーバーの1つに障害が発生すると、Windowsフェールオーバークラスターサイトがオフラインになります。詳細については、SQLServerのAlwaysOn可用性グループのWindowsフェールオーバークラスタークォーラムモードを確認してください。
データ損失のフェイルオーバー
プライマリレプリカとセカンダリレプリカの1つとの間で手動フェイルオーバーを実行しようとしていると仮定しますが、[新しいプライマリレプリカの選択]ウィンドウに、フェイルオーバー操作でプライマリおよび選択されたデータが失われる可能性があるという警告メッセージが表示されます。以下に示すように、セカンダリレプリカは同期されません：
この問題の原因を特定するために、AlwaysonAvailabilityグループダッシュボードを使用してAlwaysonHealthイベントを参照します。これは、プライマリレプリカがセカンダリレプリカへの接続を開くことができないことを示しています。以下に示す灰です。
プライマリとセカンダリ間の接続の問題を修正した後、レプリカリストを更新すると、以下に示すように、データ損失の問題が修正されていることがわかります。接続の問題のトラブルシューティングの詳細については、SQLServerデータベースエンジンへの接続のトラブルシューティングを確認してください。
可用性グループの遅延を常に監視する
可用性グループダッシュボードを変更して、以下に示すように、遅延がある理由を示すことなく、コミットLSN、送信LSN、強化LSN値など、プライマリレプリカとセカンダリレプリカ間の同期遅延に関する情報を提供する追加の列を含めることができます。
遅延の測定の詳細については、可用性グループの同期ラグの測定を確認してください。
SSMS 17.4以降、Always on Availability Groupダッシュボードが拡張され、遅延情報の計算、分析、およびレポートに使用される2つの新しいオプションが含まれるようになりました。これは、プライマリレプリカとセカンダリレプリカ間のトランザクションログフローのボトルネックを特定し、絞り込むのに役立ちます。その待ち時間の原因。
新機能とレポートの詳細については、[Always onAvailabilityGroupダッシュボードを使用する]をオンにしてください。
この新しいオプションを使用してトリガーするには、レイテンシデータの収集をクリックします [Always on Availability Group]ダッシュボードのオプション。以下に示すように、プライマリレプリカとセカンダリレプリカに新しいSQLエージェントジョブを作成して、レイテンシデータを収集します。
作成されたジョブの実行がすべてのAvailabilityGroupレプリカで完了したら、Availability Group名を右クリックし、プライマリレプリカレイテンシレポートまたはセカンダリレプリカレイテンシレポートを選択することで、レイテンシレポートからレイテンシ統計を表示できます。可用性グループのレプリカの役割。
可用性グループのレプリカに関する情報を提供した後、遅延レポートには、プライマリレプリカのトランザクションログのコミット時間とセカンダリレプリカのリモート硬化時間が平均値として集計されてグラフィカルに表示されます。また、レポートは、トランザクションログの送信、受信、コミット、圧縮、解凍、および可用性グループのレプリカの役割に基づくその他の数値の統計値を提供します。
遅延レポートの詳細については、SSMSの[新規]-[常にオンの可用性グループの遅延レポート]を確認してください。
以下のレポートは、セカンダリレプリカから生成されたレイテンシレポートの例であり、通常のログ転送操作を示しています。
また、ログブロックレイテンシ レポートには、プライマリレプリカのトランザクションログがセカンダリレプリカがそのトランザクションをコミットするのを待機する時間がミリ秒単位で表示されます。可用性グループダッシュボードから有効にした後、以前の遅延レポートと同様にSSMSから参照できます。以下に示すように、待ち時間が長いということは、プライマリレプリカがセカンダリレプリカが送信されたトランザクションをコミットするのを長時間待機していることを示していることを考慮してください。
