「AVAILABILITY_REPLICA」によってトランザクションログを再利用できなくなった（ファイル管理トラブル）：SQL Serverトラブルシューティング（27）（1/2 ページ）

連載バックナンバー

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。

トラブル 20（カテゴリー：ファイル管理）：「AVAILABILITY_REPLICA」によってトランザクションログを再利用できなくなった

　「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。

トラブルの実例：SQL Serverの可用性ソリューションの1つである「可用性グループ」（*1）を構築した環境で運用していたところ、設計当初の想定を大幅に超えるトランザクションログの肥大化に気が付いた。

（*1）AlwaysOn可用性グループの概要（SQL Server）（Microsoft Developer Network）

　このため、「sys.databases」などからトランザクションログが再利用されない原因を調べたところ、log_reuse_waitの値が「9」、ログが再利用されない理由を示すlog_reuse_wait_descの値が「AVAILABILITY_REPLICA」と表示された（図20-1）。

図20-1　「sys.databases」を確認したところ、ログが再利用できない理由として「AVAILABILITY_REPLICA」と表示された

トラブルの原因を探る

　可用性グループを構築したSQL Serverの環境では、読み書きが可能な「プライマリーレプリカ」と呼ばれるインスタンスにのみトランザクションログの更新処理を実施するよう動作します。続いて、「セカンダリーレプリカ」と呼ばれる可用性グループに属する残りのインスタンスに対して、トランザクションログレコードとして配信されます。このような流れで、全てのインスタンスで同じトランザクションログレコードが同期され、データベースの可用性が確保されます。

　sys.databasesで「AVAILABILITY_REPLICA」と表示されるステータスは、プライマリーレプリカのトランザクションログレコードがセカンダリーレプリカに適用中（配信／同期途中）である状態を示しています。可用性グループの同期状態の詳細を把握するために、「SQL Server Management Studio」から可用性グループのダッシュボードを起動して、状況を確認します（図20-2）。

図20-2　SQL Server Management Studioを確認すると、問題点が見つかった。ミラーリングモニターで「同期されていません」とあり、切断されていた

　ダッシュボードでは、「SQLNETWORKNAME」というインスタンス名のセカンダリーレプリカが「同期されていません」と表示されていました。「同期されていません」の状態になる原因は幾つかありますが、今回は、SQLNETWORKNAMEが正常に起動していなかったために、結果として可用性グループの同期も切断されていた状況だったようです。

　なお、可用性グループが構築された環境でトランザクションログを再利用できる状態にするには、以下の2つの要件を満たす必要があります。

（1）トランザクションログのバックアップを実行する

　まず、以前も解説した通常の完全復旧モデルの要件でもあった、「トランザクションログのバックアップを実行」します。

（2）プライマリーレプリカの更新データが正しく配信されるよう設定する

　続いて、可用性グループのセカンダリーレプリカにプライマリーレプリカの更新データが正しく配信されるよう設定します。こうすることで、ログの再利用が可能になります。

　もし、セカンダリーレプリカに更新データを配信する前にトランザクションログを切り捨ててしまうと、可用性グループとしてそもそも同期が取れない状況に陥ります。そうなるのを防ぐ処置である「トランザクションログを切り捨てない状態」が続いたことが、今回、トランザクションログが肥大化した原因です。