【5分で流し読み】AlwaysOn可用性グループのデータベースの正常性検出機能でできることを理解する

こんにちは。今週末はAlwaysOn可用性グループと仲良くなるために奮闘しております。

この記事では、「データベースの正常性検出」機能でできることを整理しておこうと思います。

Contents

データベースの正常性検出とは

データベース レベルの正常性検出 – SQL Server Always On | Microsoft Docs

  • SQL Server 2016で導入された機能
  • (何らかの問題が発生した場合などに)データベースがオンライン状態でなくなったことを検知して、可用性グループの自動フェールオーバーをトリガーする機能
  • データベースの高可用性を保証するため、基本的に利用が推奨されている
  • が、後方互換性のため、既定では無効化されている
  • 可用性グループ内のすべてのデータベースに適用され、データベース毎の有効/無効はできない
  • つまり、可用性グループ内のいずれかのデータベースがオンライン状態でなくなると、他のデータベースの状態に関わらず可用性グループはすぐにフェールオーバーする
  • もし、特定のデータベース群にだけこの機能適用したい場合は、それらだけをまとめた可用性グループを構成する
  • あくまでデータベースの可用性を監視するもので、その構成要素であるデータベースファイルの可用性などを直接監視するわけではない。つまり、アクティブなトランザクションがない状態でデータベースファイルにアクセスできない状態になったとしても、トランザクションがない以上は異常は検出されずフェールオーバーが行われない、とか、トランザクションがあってもキャッシュを利用してクエリに応答できていると物理読み込みが即座に発生しないため異常は検知されない、といったことはありえる
  • T-SQLまたはSSMSから有効化/無効化できる

ここで、可用性グループ構成時に設定できる”自動フェールオーバー”モードとこのデータベースの正常性検出による自動フェールオーバーって何が違うんだっけという混乱が発生。

これに対しては回答になる公式Docの記載を発見。なるほど、監視するコンポーネントのレベルが違うということか。確かに「データベースレベルの」とあえてついているのはそういうことか。

データベース レベルの正常性検出を構成していない限り、データベース レベルの問題 (データ ファイルの損失、データベースの削除、トランザクション ログの破損による障害が疑われる場合など) が発生しても、可用性グループのフェールオーバーは行われません。

可用性グループのフェールオーバー モード – SQL Server Always On | Microsoft Docs

データベースの正常性検出を利用していない場合の自動フェールオーバーは、「柔軟なフェールオーバー ポリシーにより定義されたフェールオーバー条件レベルが満たされている」ときに発生すると。

可用性グループのフェールオーバー モード – SQL Server Always On | Microsoft Docs

で、柔軟なフェールオーバーポリシーってなんだっけ。(初学者すぎて毎回こんな確認の連鎖だ・・笑)以下の公式Docsの記載を引用。

柔軟なフェールオーバー ポリシーを使用すると、可用性グループの 自動フェールオーバー を実行する条件をきめ細かく制御できます。 自動フェールオーバーを実行するエラー条件および正常性チェックの頻度を変更することで、自動フェールオーバーの確率値を増減して高可用性の SLA をサポートできます。

可用性グループの柔軟なフェールオーバー ポリシーは、そのエラー条件レベルと正常性チェックのタイムアウトしきい値によって定義されます。 可用性グループがエラー条件レベルまたはその正常性チェックのタイムアウトしきい値を超えていることを検出すると、可用性グループのリソース DLL が Windows Server フェールオーバー クラスタリング (WSFC) クラスターに応答を送り返します。 その後、WSFC クラスターは、セカンダリ レプリカに対する自動フェールオーバーを開始します。

柔軟なフェールオーバーポリシーはSSMSからは構成できず、T-SQLまたはPowerShellなどから構成する必要がある。

可用性グループに柔軟な自動フェールオーバー ポリシーを構成する – SQL Server Always On | Microsoft Docs

なるほど、自動フェールオーバーは可用性グループのエラー条件、正常性チェックタイムアウトの閾値に基づいてトリガーされるよ、ちなみにこの条件は柔軟に変えれるよ、ということがいいたいのだと理解した。

規定値は以下から確認できた。

select * from sys.availability_groups;

failure_condition_levelの数値の定義は以下。

可用性グループに柔軟な自動フェールオーバー ポリシーを構成する – SQL Server Always On | Microsoft Docs

話戻ってデータベースレベルの正常性検出とこの可用性グループの自動フェールオーバーについては、以下の記載も。上の事前知識があってはじめて理解できた笑

データベースレベルの正常性検出の条件は、可用性グループの自動フェールオーバー条件である”FAILURE_CONDITION_LEVEL”と”HEALTH_CHECK_TIMEOUT”とは別のパラメータである”DB_FAILOVER”で管理されていて、互いに独立しているよ、ということがいいたいのか。

データベース レベルの正常性検出では、フェールオーバー ポリシーに対して SQL Server プロセスの正常性のしきい値が構成された、柔軟なフェールオーバー ポリシーが実装されています。 データベース レベルの正常性検出は DB_FAILOVER パラメーターを使用して構成されますが、可用性グループ オプション FAILURE_CONDITION_LEVEL はそれとは別のもので、SQL Server プロセスの正常性検出を構成します。 この 2 つのオプションは互いに独立しています。

データベース レベルの正常性検出 – SQL Server Always On | Microsoft Docs

確かに同じsys.availability_groupsテーブルにdb_failoverパラメータも存在した。

ふう・・初学者には理解に時間がかかったよ・・・

実際に使ってみる

有効/無効の確認

再掲ですが、動的管理ビューを使って確認できるみたい。

select name, db_failover from sys.availability_groups;

有効化

以下コマンドで有効化できる。

ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = ON);

問題の再現

ここで、データベースをオフラインにするような問題を意図的に発生させられればと思ったけど、方法が分からず断念・・

単純にオフラインする方法は、可用性グループを組んでいればできないようだ。

Msg 1468, Level 16, State 1, Line 3
The operation cannot be performed on database "MyDB1" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.
Msg 5069, Level 16, State 1, Line 3
ALTER DATABASE statement failed.

なんか良い方法があれば続きを試してみたいと思いますが、まあ、機能については理解することができたのでいったんここまで・・。

少しでも参考になりましたら幸いです。

おしまい

この記事を気に入っていただけたらシェアをお願いします!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

ABOUT US
Yuu113
初めまして。ゆうたろうと申します。 兵庫県出身、東京でシステムエンジニアをしております。現在は主にデータ分析、機械学習を活用してビジネスモデリングに取り組んでいます。 日々学んだことや経験したことを整理していきたいと思い、ブログを始めました。旅行、カメラ、IT技術、江戸文化が大好きですので、これらについても記事にしていきたいと思っています。