本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「可用性グループ/AVAILABILITY_REPLICAに関連するトランザクションログトラブルの対処方法」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。
「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。
トラブルの実例:SQL Serverの可用性ソリューションの1つである「可用性グループ」(*1)を構築した環境で運用していたところ、設計当初の想定を大幅に超えるトランザクションログの肥大化に気が付いた。
このため、「sys.databases」などからトランザクションログが再利用されない原因を調べたところ、log_reuse_waitの値が「9」、ログが再利用されない理由を示すlog_reuse_wait_descの値が「AVAILABILITY_REPLICA」と表示された(図20-1)。
可用性グループを構築したSQL Serverの環境では、読み書きが可能な「プライマリーレプリカ」と呼ばれるインスタンスにのみトランザクションログの更新処理を実施するよう動作します。続いて、「セカンダリーレプリカ」と呼ばれる可用性グループに属する残りのインスタンスに対して、トランザクションログレコードとして配信されます。このような流れで、全てのインスタンスで同じトランザクションログレコードが同期され、データベースの可用性が確保されます。
sys.databasesで「AVAILABILITY_REPLICA」と表示されるステータスは、プライマリーレプリカのトランザクションログレコードがセカンダリーレプリカに適用中(配信/同期途中)である状態を示しています。可用性グループの同期状態の詳細を把握するために、「SQL Server Management Studio」から可用性グループのダッシュボードを起動して、状況を確認します(図20-2)。
ダッシュボードでは、「SQLNETWORKNAME」というインスタンス名のセカンダリーレプリカが「同期されていません」と表示されていました。「同期されていません」の状態になる原因は幾つかありますが、今回は、SQLNETWORKNAMEが正常に起動していなかったために、結果として可用性グループの同期も切断されていた状況だったようです。
なお、可用性グループが構築された環境でトランザクションログを再利用できる状態にするには、以下の2つの要件を満たす必要があります。
まず、以前も解説した通常の完全復旧モデルの要件でもあった、「トランザクションログのバックアップを実行」します。
続いて、可用性グループのセカンダリーレプリカにプライマリーレプリカの更新データが正しく配信されるよう設定します。こうすることで、ログの再利用が可能になります。
もし、セカンダリーレプリカに更新データを配信する前にトランザクションログを切り捨ててしまうと、可用性グループとしてそもそも同期が取れない状況に陥ります。そうなるのを防ぐ処置である「トランザクションログを切り捨てない状態」が続いたことが、今回、トランザクションログが肥大化した原因です。
Copyright © ITmedia, Inc. All Rights Reserved.