こんばんは。この週末は、ちゃんと理解したいと思っていてずっと重い腰のあがっていなかったSQL ServerのAlways On可用性グループについて、ついに調べてみました。
公式ドキュメントやいろんな外部Webサイトの説明をもとにまとめていますが、理解が正しくない部分もあるかもしれません。そうした際にはご指摘をいただけましたら幸いです。
それではまいります！
Contents
Always On可用性グループ(AG)とは
- 従来のデータベースミラーリングに代わる、HADR（高可用性・耐災害性）を実現するSQL Serverの機能で、SQL Serverの可用性を最大化する
- いつでも（Always）オンライン（Online）にする、という意味でAlwaysOnという機能名
- SQL Server 2012以降で利用可能
- 複数のSQL Serverを束ねて（可用性グループと呼ぶ）仮想的に１つのSQL Serverにみせ、グループの１台が正常に機能していれば、接続元からは正常に動作しているように見せることができる
参考：
https://qiita.com/zaburo/items/5ca86becda6023b90f7e
https://codezine.jp/article/detail/6480
AlwaysOn可用性グループの構成要素
続けて、AlwaysOn可用性グループの構成をもう少し細かく見ていきたいと思います。参考文献に記載の各種説明を読んで、以下のように理解しました。
- 可用性グループ：可用性レプリカを束ねたもの。このグループ内でフェールオーバーが行われる。WSFC (Windows Server Failover Cluster)というテクノロジを利用してレプリカをクラスタ化している。
- 可用性レプリカ：可用性グループ内の可用性データベースのコピーをホスト。プライマリレプリカとセカンダリレプリカが存在する。
- プライマリレプリカ：プライマリ ロールが割り当てられ、 プライマリ データベースと呼ばれる読み取り/書き込みデータベースをホストする。
- セカンダリレプリカ：セカンダリ ロールが割り当てられ、セカンダリ データベースと呼ばれる読み取り専用のデータベースをホストし、フェールオーバーターゲットとして機能する
- 可用性データベース：可用性グループに参加するデータベース。可用性レプリカ上にホストされている
- 可用性グループ リスナー：Always On 可用性グループのプライマリ レプリカまたはセカンダリ レプリカ内のデータベースにアクセスするためにクライアントが接続できるサーバー名。リスナーを使用すると、クライアントは、SQL Server の物理インスタンス名を知らなくても、レプリカに接続できる。
Windows Serverにおいて、アプリケーションとサービスの可用性を向上するために動作する独立したサーバーのグループ。Windows Serverのクラスターを構成できる。
以下の説明が参考になると思います。
参考文献：
AlwaysOn可用性グループの動作
機能の概要と構成要素が分かったところで、次は具体的な動作を確認していきたいと思います。
具体的には、同期とフェールオーバーの仕組みについて理解しておくとよさそうです。
同期の動作
動作の概要
- データ同期では、同期コミットモードと非同期コミットモードという２つの形式がサポートされる（可用性モードともいう）。
- 同期コミットモードでは、パフォーマンスよりも高可用性が重視され、可用性が向上する一方トランザクションの遅延が増加するのが欠点。詳細は次章。
- 非同期コミットモードは、同期によるデータ保護よりもパフォーマンスが重視される。可用性レプリカが離れた距離に分散されている場合に正常に利用できる災害復旧ソリューション。詳細は次章。
- セカンダリが可用性グループに参加すると、セカンダリ データベースは ONLINE 状態になり、対応するプライマリ データベースとのデータ同期が開始される。
- データ同期では、プライマリ データベースがトランザクション ログ レコードがセカンダリ データベースに送信される
- すべてのセカンダリ レプリカは、トランザクション ログ レコードをキャッシュし (ログの書き込み )、それを対応するセカンダリ データベースに適用する
- データ同期は、プライマリ データベースと接続されているそれぞれのセカンダリ データベースとの間で、他のデータベースとは無関係に発生。なので、あるセカンダリの動作不良が他のセカンダリの同期に影響を及ぼすことはない。
同期コミット・非同期コミット
同期コミット、非同期コミットについては、文献などを読んで以下の流れと理解しました。
同期コミットの流れ
なお、同期コミットでは、以下のシナリオでデータの同期が行われなくなることが想定されます。このため、プライマリがセカンダリから確認メッセージを受信する前にタイムアウトした場合には、プライマリはそのセカンダリを”失敗”として認識し、セカンダリレプリカの接続状態は”DISCONNECTED”に変更され、プライマリは確認メッセージの受信待機をとりやめます。
- プライマリ・セカンダリレプリカ間のネットワーク遅延・不具合などが原因でセッションがタイムアウトになった
- セカンダリレプリカ上のセカンダリデータベースが中断された（同期状態がNOT_HEALTHY）
- プライマリデータベースを可用性グループに追加した。この場合以前に同期されたセカンダリレプリカはNOT_HEALTHY状態となり、対応するセカンダリデータベースが準備され、可用性グループに参加し、新しいプライマリデータベースと同期されるまでHEALTHYとならない。
- プライマリまたはセカンダリレプリカを非同期コミット可用性モードへ変更した。
- セカンダリレプリカを同期コミット可用性モードに変更した。
非同期コミットの流れ
上のフローで、プライマリがセカンダリからの確認メッセージの受信を待たないものと理解しました。
こちらも文献などを読んで以下のように理解しました。
- 同期コミットでは、プライマリ・セカンダリは常に同期された状態を維持できるため、高い可用性を維持できるものの、同期に要する時間や、種々の接続の問題で大きな待機時間が発生してしまう可能性がありますので、プライマリのパフォーマンスは非同期コミットと比べて低下する。
- なので、プライマリレプリカから物理的に非常に離れた場所にセカンダリレプリカがあったり、同期に関する軽度のエラーが与えるプライマリレプリカへの影響が許容できない場合には、非同期コミットが有効な対策になりえる。非同期コミットでは、プライマリのパフォーマンスは同期コミットと比較して向上するが、プライマリの変更がセカンダリに反映しきれていないタイミングでフェールオーバーが発生した場合など、タイミングによってはデータの損失が発生し得る。
- ので、結局のところビジネスとして許容できる基準に応じて選択すべし。
参考：
フェールオーバーの動作
動作の概要
- フェールオーバーには、自動フェールオーバー、計画的な手動フェールオーバー、強制フェールオーバーの３つの形式がある
- 自動・計画的な手動フェールオーバーではデータの損失が発生しないが、強制フェールオーバーではデータの損失が発生し得る
- どの形式が利用できるかは、可用性モードによって決まる（以下チャートで整理）
- 可用性レプリカでは、1 つの可用性グループ内のデータベースのセットに対してデータセット レベルでのみ冗長性が提供されます。
- 可用性グループは、可用性レプリカのレベルでフェールオーバーする
- なので、データベースの問題 (たとえば、データ ファイルの損失、データベースの削除、トランザクション ログの破損による障害が疑われる場合など) が発生してもフェールオーバーは行われない
- 最大 9 つの可用性レプリカ（1 個のプライマリ レプリカと最大 8 個のセカンダリ レプリカ）がサポートされる
自動フェールオーバー
以下の流れで行われます。
自動フェールオーバーの前提条件はこちらにまとまっています。
計画的な手動フェールオーバー
以下の流れで行われます。
前提条件はこちらにまとまっています。
強制フェールオーバー
以下の流れで行われます。
参考文献：
以上、SQL ServerのAlways On可用性グループについてのまとめでした。
少しでも参考になりましたら幸いです。
おしまい
こちらのブログに分かりやすく違いがまとめられていました。目指すもの（高可用性）や考え方、操作方法はおおよそ同じなものの、細かくはいろいろと違うようです。（セカンダリが１つしか構成できない、ミラーリング監視サーバが別途必要、など。総じてAlwaysOn可用性グループの方が利便性が高いように見受けられます。）
http://www.sqlquality.com/Self2012/Self2012_NewAlwaysOn/Text/Step02-01.html
なお、AlwaysOn可用性グループの登場によってその役目を終えた模様で、公式ドキュメントにも、ミラーリングは将来のリリースで機能廃止予定で、今後はAlwaysOn可用性グループを使用するようにと明記されていますので、SQL Serverにおいては今後新たに利用することはなさそうです。
公式Doc：
https://docs.microsoft.com/ja-jp/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-ver15