web-dev-qa-db-ja.com

フェイルオーバー後、可用性グループデータベースが長時間リバート状態になる

アーキテクチャ：私は2 Node Sync-Commit AlwaysOn構成をマルチサブネットフェールオーバークラスターで実行しています。プライマリノードはヨーロッパとセカンダリノードは米国にあります。可用性グループには、SCOMのOperationsManager dbというデータベースが1つだけあります。

  • プライマリホストとセカンダリホストは同じです。
  • 両方のボックスのSQL Serverバージョン：13.0.5237およびWindows Core
  • 更新：両方のサーバーに10.0.5270.0にパッチを適用しましたが、役に立ちませんでした。
  • DB VLFカウントは27のみです。

問題：フェイルオーバーを開始すると、データベースがプライマリノードからセカンダリノードに数秒でフェイルオーバーします。ただし、新しいセカンダリ（古いプライマリ）データベースは、元に戻す/回復フェーズに入り、そこに約30分間留まります。元のプライマリボックスにフェイルバックしているときにも同じことが発生したため、両方の方法で発生する問題です。

調査結果：インターネットでこれについて検索し、ドキュメントを読んで問題を調査しました。プライマリからセカンダリへの役割の変更が完了すると、新しいセカンダリデータベースは3つのフェーズを通過します。

同期状態：「同期していません」;データベースの状態：ONLINE

同期状態：「同期していません」;データベースの状態：回復中

同期状態：「REVERTING」;データベースの状態：回復中

私の場合、すべての時間が最後のステップに費やされています。また、perfmonカウンター「SQLServer：Database ReplicaLog残りfor undo」を調べて、元に戻すプロセスを監視しました

フェールオーバーテストの前にプライマリサイトをチェックして、実行時間の長いトランザクションまたは開いているトランザクションを見つけましたが、見つかりませんでした。フェイルオーバー後の「元に戻すためのログの残り」は約30MBで、セカンダリデータベースが「同期済み」の状態に戻るまでに30分かかりました。 Sync-Commitモードで実行しており、プライマリに少しのワークロードがあることを考慮すると、やり直しフェーズで30分かかるはずはありません。

SQL Serverエラーログ：この奇妙なメッセージを見つけました。

  • LSN（2558：107841：1）のデータベース 'OperationsManager'で2019年2月22日2:55 PMに開始されたトランザクション 'RECEIVE MSG'（ID 0x000000004d52c65a 0001：01c4e415）のリモート強化は失敗しました。

  • LSN（2558：107843：46）のデータベース 'OperationsManager'で2019年2月22日2:59 PMに開始されたトランザクション 'GhostCleanupTask'（ID 0x000000004d6d15aa 0001：01c4eaa0）のリモート強化は失敗しました。

フェイルオーバーが開始されます： enter image description here

enter image description here

フェイルオーバーの終了： enter image description here

概して

この問題を見たことがありますか？何かお勧めはありますか？

sql-serveravailability-groups
4
Bahtiyar Samet Çoban

通常の復元であるかAGフェイルオーバーであるかに関係なく、データベースの回復が長時間実行されている場合は必ず確認することは、VLF count。多数のVLF（数千または数万））、または異常なサイズ（1つまたは2つの非常に大きなVLF）は、このプロセスの速度を遅くします。

問題のデータベースで次のコマンドを実行します。

USE YourDatabaseName;
GO

DBCC LOGINFO;

注：SQL Server 2016 SP2以降を使用している場合は、DBCCコマンドの代わりにこの動的管理機能を使用できます： sys.dm_db_log_info

戻ってくる行の数は、持っているVLFの数です。その数が非常に大きい場合、またはFileSize列にVLF間の極端な外れ値が示されている場合は、（高レベルで）スローリカバリの問題を解決できる可能性があります。

  1. ログファイルをできるだけ小さくする
  2. 目標のサイズに戻す
  3. 通常のログ増加率とトランザクションログバックアップの頻度に基づいて、自動拡張が適切な数に設定されていることを確認する

修正の詳細VLFサイジングの問題は、他の場所で広くカバーされています。ここに1つの例を示します： 忙しい/偶発的なDBAのVLF管理ガイド

3
Josh Darnell

すでに答えたように、VLFも最初の選択です。2つのノード間のインフラマッチングを検討することも検討します。

はい、サーバーをセットアップして準備ができるようにセットアップする前に、これらを考慮する必要があることを知っています。しかし、シナリオの1つで他のノードがプライマリレプリカノードと比較してまったく異なるストレージシステムを提供していた場合のように、それは時々発生します。 SANストレージはセカンダリレプリカ上にありますが、ストレージチームからのミスであり、フェイルオーバーを実行しているとき、SSDがプライマリレプリカにありましたが、しばらく時間がかかっているようです。

最善の策は、すべてのパフォーマンスメトリックを収集し、2つのレプリカを比較して、すべてが正常に見えるかどうかを確認することです。同じである必要はありませんが、DRのテストを行い、AGフェイルオーバー後に他のデータセンターまたは新しいプライマリレプリカから負荷を実行する場合に適しています。

2
KASQLDBA

クライアントのデータベースにも同じ問題があり、根本的な原因は、FreeBCPを使用してデータを一括挿入するクライアントからの大量のデータでした。私たちの回避策は、手動での常時フェイルオーバーの前に一括挿入をオフにすることでした。

1
tazzman