Always On 可用性グループでのログ送信キューのトラブルシューティング
この記事では、ログ送信キューに関連する問題を解決します。
ログ送信キューとは
プライマリ レプリカ上の可用性グループ データベース ( INSERT、 UPDATE、 DELETEなど) に加えられた変更は、トランザクション ログに書き込まれ、可用性グループのセカンダリ レプリカに送信されます。 Log 送信キューは、セカンダリ レプリカに送信されていないプライマリ データベースのログ ファイル内のログ レコードの数を定義します。
ログ送信キューの症状と影響
ログ送信キューには、脆弱なすべてのデータが格納されます
突然の障害でプライマリ レプリカが失われ、これらの変更がまだ到着していないセカンダリ レプリカにフェールオーバーした場合、それらの変更はデータベースの新しいプライマリ レプリカ コピーには表示されません。 これにより、データベースとログの完全バックアップの実行時に保存される変更は除外されます。
ログ送信キューの増加により、トランザクション ログ ファイルの増加が発生する
可用性グループで定義されているデータベースの場合、Microsoft SQL Server は、セカンダリ レプリカにまだ配信されていないトランザクション ログ内のすべてのトランザクションをプライマリ レプリカに保持する必要があります。 ログ送信キューは、プライマリ レプリカでログに記録された変更の量を表します。この変更は、通常のログ切り捨てイベント (データベース ログ バックアップ中など) に切り捨てることはできません。 大きく増大するログ送信キューでは、データベース ログ ファイルをホストするドライブの空き領域が使い果たされたり、構成されている最大トランザクション ログ ファイル サイズを超えたりする可能性があります。 詳細については、「トランザクション ログが大きい場合のエラー 9002 のを参照してください。
可用性グループ のログ送信キューに関するさまざまな診断機能レポート
SQL Server Management Studio の Always On ダッシュボードは、ログ送信キューに関するレポートを表示します。 可用性グループが異常であると報告される場合があります。
ログ送信キューを確認する方法
ログ送信キューは、データベースごとの測定です。 この値は、プライマリ レプリカの Always On ダッシュボードを使用するか、プライマリ レプリカまたはセカンダリ レプリカの sys.dm_hadr_database_replica_states 動的管理ビュー (DMV) を使用して確認できます。 パフォーマンス モニター カウンターは、セカンダリ レプリカに対するログ送信キューの確認に使用されます。
次のいくつかのセクションでは、可用性グループ のデータベース ログ送信キューをアクティブに監視する方法について説明します。
クエリ sys.dm_hadr_database_replica_state
sys.dm_hadr_database_replica_states DMV は、可用性グループ データベースごとに 1 行を報告します。 そのレポート内の 1 つの列が log_send_queue_size。 この値は、ログ送信キューのサイズ (KB 単位) です。 次のクエリなどのクエリを設定して、ログ送信キューのサイズの傾向を監視できます。 クエリはプライマリ レプリカで実行されます。 log_send_queue_sizeとlog_send_rateが関連するセカンダリ レプリカのデータをレポートするには、is_local=0述語を使用します。
WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.log_send_queue_size, drs.log_send_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
waitfor delay '00:00:30'
END
出力は次のようになります。
Always On ダッシュボードでログ送信キューを確認する
ログ送信キューを確認するには、次の手順に従います。
SSMS オブジェクト エクスプローラーの可用性グループを右クリックして、SQL Server Management Studio (SSMS) で Always On ダッシュボードを開きます。
[ダッシュボードの表示] 選択。
可用性グループ データベースは最後に一覧表示され、データベースに関していくつかのデータが報告されます。 Log Send Queue Size (KB)と Log Send Rate (KB/sec)) は既定では表示されませんが、次の手順のスクリーンショットに示すように、このビューに追加できます。
これらの列を追加するには、可用性グループ データベースの列ヘッダーを右クリックし、使用可能な列の一覧から選択します。
ログ送信キュー サイズの追加 するには次のスクリーンショットで赤で強調表示されているヘッダーを右クリックします。
既定では、Always On ダッシュボードでは、このデータが 60 秒ごとに自動更新されます。
パフォーマンス モニターでログ送信キューを確認する
ログ送信キューは、各セカンダリ レプリカ データベースに固有です。 そのため、可用性グループ データベースのログ送信キューを確認するには、次の手順に従います。
セカンダリ レプリカでパフォーマンス モニターを開きます。
追加 (カウンター) ボタンを選択します。
Available カウンターで、SQLServer:Database Replica および Log Send Queue カウンターを選択します。
Instance リスト ボックスで、ログ送信キューを確認する可用性グループ データベースを選択します。
[追加選択しOKします。
ログ送信キューの増加は次のようになります。
ログ送信キュー値の解釈
このセクションでは、ログ送信キューサイズの値を解釈する方法について説明します。
ログ送信キューが正しくないのはいつですか? どの程度のログ送信キューを許容する必要がありますか?
ログ送信キューが 0 の値を報告している場合は、そのレポートの時点でログ送信キューが発生していないと想定できます。 ただし、運用環境がビジー状態の場合は、正常な AlwaysOn 環境であっても、ログ送信キューが 0 以外の値を頻繁に報告することを想定する必要があります。 一般的な運用環境では、この値が 0 から 0 以外の値の間で変動することを想定する必要があります。
時間の経過と伴うログ送信キューの増加を確認した場合は、さらなる調査が必要です。 この追加アクティビティは、何かが変更されたことを示します。 ログ送信キューが急激に増加する場合は、トラブルシューティングに次の測定値が役立ちます。
- Log Send Rate (KB/sec) (AlwaysOn ダッシュボード)
- sys.dm_hadr_database_replica_states (DMV)
- データベース レプリカ::ミラー化されたトランザクション/秒 (パフォーマンス モニター)
1 秒あたりのログ送信レートとミラー化トランザクションのベースライン レートを取得する
正常な AlwaysOn パフォーマンス中に、ビジー状態の可用性グループ データベースの ログ送信レート および mirrored トランザクション数/秒 値を監視します。 一般的に忙しい営業時間中はどのように表示されますか? 大規模なトランザクションがシステムのトランザクション スループットを向上させる場合、メンテナンス期間中はどのように表示されますか? ログ送信キューの増加を観察するときにこれらの値を比較して、何が変更されたかを判断できます。 ワークロードが通常より大きい場合があります。 ログ送信速度が通常よりも低い場合は、理由を特定するためにさらに調査が必要になる場合があります。
ワークロードボリュームが重要
大規模なワークロード (100 万行に対する UPDATE ステートメント、1 テラバイト のテーブルでのインデックスの再構築、数百万行を挿入している ETL バッチなど) がある場合は、すぐにまたは時間の経過と同時に、ログ送信キューの増加が予想されます。 これは、可用性グループ データベースで大量の変更が突然行われる場合に想定されます。
ログ送信キューを診断する方法
特定の可用性グループ データベースのログ送信キューを特定したら、次のセクションで説明するように、問題の考えられるいくつかの根本原因を確認する必要があります。
重要
意味のある待機の種類の出力については、次の条件を監視するときに、前のセクションで説明したいずれかの方法を使用して、ログ送信キューの増加を確認します。
システムがビジー状態です
プライマリ レプリカのワークロードがシステムの CPU をオーバーロードしているかどうかを確認します。 ログ送信キューが増加している場合は、 sys.dm_os_schedulers DMV に対してクエリを実行し、 high runnable_tasks_countを監視します。 この数は、その時点で実行された未処理のタスクを示します。
SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, runnable_tasks_count, current_workers_count, active_workers_count
FROM sys.dm_os_schedulers
次の表は、結果のサンプルです。 runnable_tasks_count値の増加は、多数のタスクが CPU 時間を待機していることを示します。
| scheduler_address | scheduler_id | cpu_id | status | current_tasks_count | runnable_tasks_count | current_workers_count | active_workers_count |
|---|---|---|---|---|---|---|---|
| 0x000002778D 200040 | 0 | 0 | オフラインで表示 | 1 | 0 | 2 | 1 |
| 0x000002778D 220040 | 1 | 1 | VISIBLE ONLINE | 108 | 12 | 115 | 107 |
| 0x000002778D 240040 | 2 | 2 | VISIBLE ONLINE | 113 | 2 | 123 | 113 |
| 0x000002778D 260040 | 3 | 3 | VISIBLE ONLINE | 105 | 11 | 116 | 105 |
| 0x000002778D 480040 | 4 | 4 | VISIBLE ONLINE | 108 | 15 | 117 | 108 |
| 0x000002778D 4A0040 | 5 | 5 | VISIBLE ONLINE | 100 | 25 | 110 | 99 |
| 0x000002778D 4C0040 | 6 | 6 | VISIBLE ONLINE | 105 | 23 | 113 | 105 |
| 0x000002778D 4E0040 | 7 | 7 | 目に見える | 109 | 25 | 116 | 109 |
| 0x000002778D 700040 | 8 | 8 | VISIBLE ONLINE | 98 | "10" | 112 | 98 |
| 0x000002778D 720040 | 9 | 9 | VISIBLE ONLINE | 114 | 1 | 130 | 114 |
| 0x000002778D 740040 | 10 | 10 | VISIBLE ONLINE | 110 | 25 | 120 | 110 |
| 0x000002778D 760040 | 11 | 11 | VISIBLE ONLINE | 83 | 8 | 93 | 83 |
| 0x000002778D A00040 | 12 | 12 | VISIBLE ONLINE | 104 | 4 | 117 | 104 |
| 0x000002778D A20040 | 13 | 13 | VISIBLE ONLINE | 108 | 32 | 118 | 108 |
| 0x000002778D A40040 | 14 | 14 | VISIBLE ONLINE | 102 | 12 | 113 | 102 |
| 0x000002778D A60040 | 15 | 15 | VISIBLE ONLINE | 104 | 16 | 116 | 103 |
解決策: runnable_task_countが多いと検出された場合は、システムのワークロードを減らすか、システムで使用できる CPU の数を増やします。
ネットワーク待機時間
この状態は、セカンダリ レプリカがプライマリ レプリカから物理的にリモートである場合に特に一般的です。 マルチサイト可用性グループを使用すると、ディザスター リカバリーとレポートのために、ビジネス データのコピーを複数のサイトに展開できます。 これにより、リモートの場所にある実稼働データのコピーでほぼリアルタイムの変更を使用できるようになります。
セカンダリ レプリカがプライマリ レプリカから遠く離れた場所でホストされている場合は、ネットワーク待機時間が原因で、プライマリ レプリカ データベースで生成されるのと同じ速度でリモート セカンダリに変更を送信できないことが原因で、ログ送信キューが発生する可能性があります。
重要
SQL Server では、1 つの接続を使用して、プライマリレプリカからセカンダリ レプリカへの変更を同期します。 そのため、セカンダリ レプリカがリモートの場合、パイプの幅は SQL Server が送信できるデータの量には影響しません。 代わりに、この量は、パイプ内のネットワーク待機時間 (接続速度) によって異なります。
ネットワーク待ち時間のテスト
フロー制御設定がネットワーク待機時間に影響するかどうかを確認する
Microsoft SQL Server 可用性グループでは、フロー制御ゲートを使用して、すべての可用性レプリカでネットワーク リソース、メモリ、およびその他のリソースが過剰に消費されないようにします。 これらのフロー制御ゲートは、可用性レプリカの同期正常性状態には影響しません。 ただし、RPO を含む可用性データベースの全体的なパフォーマンスに影響を与える可能性があります。
以降のバージョンの SQL Server では、フロー制御が入力されるしきい値が変更されます。 これは、フロー制御がログ送信キューなどの症状に与える影響を軽減するのに役立ちます。 フロー制御とフロー制御しきい値の変更履歴の詳細については、「 フロー制御ゲートを参照してください。
パフォーマンス モニターを使用してプライマリ レプリカ上のデータをキャプチャすることで、フロー制御を監視できます。 データベース フロー制御を監視するには、 SQLServer:Database Replica カウンターを追加し、 Database Flow Control Delay および Database Flow Controls/sec カウンターを選択します。 Instance ダイアログ ボックスで、データベース フロー制御を確認する可用性グループ データベースを選択します。 可用性レプリカのフロー制御を検出して監視するには、 SQLServer:Availability Replica カウンターを追加し、 Flow Control Time (ms/sec) カウンターと Flow Control/sec カウンターを選択します。
輻輳 Windows 再起動がネットワーク待ち時間に寄与するかどうかを確認する
ログ送信キューの原因となるネットワーク パフォーマンスの問題は、 Congestion Windows Restart TCP 設定を True に設定することでトリガーできます。 これは Windows Server 2016 の既定の設定でした。 ログ送信キューが監視される可用性グループ レプリカをホストする Windows サーバーで、 Congestion Window Restart が False に設定されていることを確認します。
PS C:\WINDOWS\system32> Get-NetTCPSetting | Select SettingName, CwndRestart
TCP 輻輳 Windows Restart プロパティを False に設定する方法の詳細については、「Set-NetTCPSetting (NetTCPIP)を参照してください。
同期プロセスの詳細については Always On 可用性グループの Monitor のパフォーマンスに関する情報も参照してください。 この記事では、主要なメトリックの一部を計算する方法と、一般的なパフォーマンスのトラブルシューティング シナリオへのリンクも示します。
ping を使用して待機時間のサンプルを取得する
node1 (プライマリ レプリカ) のコマンド ラインで、node2 (セカンダリ レプリカ) に ping を実行します。
C:\Users\customer>ping node2 Pinging node2.customer.corp.company.com [<ip address>] with 32 bytes of data: Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=97ms Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=119ms Ping statistics for 2<ip address>: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 94ms, Maximum = 119ms, Average = 101ms独立したツールを使用してプライマリからセカンダリへのネットワーク スループットをテストする
単一の接続を使用してプライマリ レプリカとセカンダリ レプリカ間のネットワーク スループットを個別に検出するには、NTttcp などのツールを使用します。 ネットワーク待機時間は、ログ送信キューの一般的な原因です。 次の手順では、NTttcp などの独立したツールを使用してネットワーク スループットを測定する方法を示します。
重要
SQL Server は、1 つの接続を使用して、プライマリ レプリカからセカンダリ レプリカに変更を送信します。 次のセクションでは、(SQL Server と同じ方法で) 1 つの接続を使用してスループットを正確に比較するように、 NTttcp を構成して実行します。
NTttcp は、 Github - microsoft/ntttcp からダウンロードできます。
NTttcpを実行するには、次の手順に従います。
ツールをダウンロードして、プライマリおよびセカンダリの SQL Server ベースのサーバーにコピーします。
セカンダリ レプリカ サーバーで、管理者特権のコマンド プロンプト ウィンドウを開き、ディレクトリを NTttcp ツール フォルダーに変更し、次のコマンドを実行します。
ntttcp.exe -r -m 1,0,<secondaryipaddress>-a 16 -t 60Note
このコマンドでは、
<secondaryipaddress>はセカンダリ レプリカ サーバーの実際の IP アドレスのプレースホルダーです。プライマリ レプリカ サーバーで、管理者特権のコマンド プロンプト ウィンドウを開き、ディレクトリを NTttcp ツール フォルダーに変更してから、セカンダリ レプリカ サーバーの実際の IP アドレスをもう一度指定して次のコマンドを実行します。
ntttcp.exe -s -m 1,0,<secondaryipaddress>-a 16 -t 60次のスクリーンショットは、セカンダリ レプリカとプライマリ レプリカで実行されている NTttcp を示しています。 ネットワーク待機時間のため、ツールは 739 KB/秒のデータのみを送信できます。 これは、SQL Server が送信できることを期待できることです。
セカンダリ レプリカ上の NTttcp
プライマリ レプリカ上の NTttcp
パフォーマンス モニター カウンターを確認する
NTttcp が報告する内容を確認します。 大規模なトランザクションは、プライマリ レプリカ上の SQL Server で実行されます。 プライマリ レプリカでパフォーマンス モニターを開始した後、Network Interface::Bytes Sent/sec カウンターを追加します。 このカウンターは、プライマリ レプリカが約 777 KB/秒のデータを送信できることを確認します。 これは、NTttcp テストによって報告される 739 KB/秒の値に似ています。
また、プライマリ レプリカの SQL Server::D atabases::Log Bytes Flushed/sec 値を、セカンダリ レプリカ上の同じデータベースの SQL Server::D atabase Replica::Log Bytes Received/sec と比較すると便利です。 平均すると、"agdb" データベースに作成された最大 20 MB/秒の変更が観察されます。 ただし、セカンダリ レプリカは平均で 5.4 MB の変更のみを受け取っています。 これにより、セカンダリ レプリカにまだ送信されていないデータベース トランザクション ログの未解決の変更のプライマリ レプリカでログ送信キューが作成されます。
"agdb" データベースに対してフラッシュされたプライマリ レプリカ ログバイト数/秒
データベース agdb のセカンダリ レプリカ ログの受信バイト数/秒
