「Microsoft SQL Server」が稼働するデータベースシステムを運用する管理者に向け、「動的管理ビュー」の活用を軸にしたトラブル対策のためのノウハウを紹介していきます。今回は、Always On 可用性グループにおけるデータベースの正常性に関する情報の出力について解説します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で使用可能な動的管理ビューについて、動作概要や出力内容などを紹介していきます。今回は、Always On 可用性グループにおけるデータベースの正常性に関する情報を出力する「sys.dm_hadr_database_replica_cluster_states」について解説します。対応バージョンはSQL Server 2012以降です。
Always On 可用性グループには、複数の可用性データベースを含めることができます。可用性グループにおいて、レプリカの役割(プライマリ、セカンダリ)の変更は可用性レプリカごとに行われますが、同期処理は可用性データベースごとに行われます。
「sys.dm_hadr_database_replica_cluster_states」動的管理ビューを出力することで、可用性データベースの正常性に関する情報を出力できます。この動的管理ビューを使用して、セカンダリデータベースへのフェールオーバーの準備が整っているか、同期が中断されていないか、さらには強制フェールオーバー時の復旧ポイントなどの情報も確認できます。
列名 | データ型 | 説明 |
---|---|---|
replica_id | uniqueidentifier | 可用性レプリカ ID |
group_database_id | uniqueidentifier | 可用性データベース ID 可用性データベースの全てのレプリカで同値 |
database_name | sysname | 可用性データベース名 |
is_failover_ready | bit | プライマリデータベースと同期され、フェールオーバーの準備ができているか 0 = 準備できていない 1 = 準備できている |
is_pending_secondary_suspend | bit | 強制フェールオーバー後に、データベースの同期が中断されているか 0 = 中断されていない 1 = 中断されている NULL = 不明 (クォーラムなし) |
is_database_joined | bit | 可用性レプリカ上で可用性データベースが可用性グループに参加しているか 0 = 可用性グループに参加していない 1 = 可用性グループに参加している NULL = 不明 (クォーラムなし) |
recovery_lsn | numeric(25,0) | プライマリレプリカでの復旧後またはフェールオーバー後、レプリカが新しいログレコードを書き込む前のトランザクションログの末尾 |
truncation_lsn | numeric(25,0) | プライマリレプリカの最小のログ切り捨て値 |
3つの可用性レプリカで構成された1つの可用性グループを構成しました(図1)。
2つの可用性レプリカが同期コミット、1つの可用性レプリカが非同期コミットで構成されています(図2)。
プライマリレプリカに接続し、「sys.dm_hadr_database_replica_cluster_states」動的管理ビューを出力します(図3)。
出力結果から、同期コミットに構成された可用性データベースでは「is_failover_ready」列の値が「1」となっており、フェールオーバーの準備が整っていることが分かります。非同期コミットのセカンダリレプリカでは、最新のトランザクションが配布されている状況でも、「is_failover_ready」列の値は「0」となっています。
次に、同期コミットのセカンダリレプリカインスタンスを停止して、「sys.dm_hadr_database_replica_cluster_states」動的管理ビューを出力します。停止したセカンダリレプリカの「is_failover_ready」列の値が「0」になりました(図4)。
セカンダリレプリカインスタンスを再開せずに、プライマリレプリカで更新処理を繰り返しながら、トランザクションログバックアップを何回か実行します。
可用性データベースでは、セカンダリレプリカに配布されていないトランザクションログは切り捨てられませんので、「sys.databases」カタログビューの「log_reuse_wait_desc」列の値を確認すると「AVAILABIRITY_REPLICA」となっており、ログの切り捨てを待機させる原因が可用性レプリカであることを確認できます(図5)。
プライマリレプリカで更新処理を繰り返しながら「sys.dm_hadr_database_replica_cluster_states」動的管理ビューの「truncation_lsn」列の値を確認すると、値が変化しないことが確認できます(図6)。
停止していたセカンダリレプリカを再開し、セカンダリレプリカの同期が再開されると、ログの切り捨ても再開され「truncation_lsn」列の値は更新されました。
※本Tipsは、「Windows Server 2019」上に「SQL Server 2019 CTP2」をインストールした環境を想定して解説しています。
日本ユニシス株式会社所属。Microsoft MVP for Data Platform(2017~)。入社以来 SQL Serverの評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。
日本ユニシス株式会社所属。入社以来SQL Server一筋で評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。社内のプログラミングコンテストで4回の優勝経験も持つ。趣味は輪行で週末は自転車を持っての旅行。目標は色々な日本百選を制覇すること。
Copyright © ITmedia, Inc. All Rights Reserved.
Database Expert 險倅コ九Λ繝ウ繧ュ繝ウ繧ー