分散可用性グループの直接シードに失敗しました、failure_state SQLエラー、failure_state 2
分散型可用性グループ のセットアップを開始し、本番データベースを新しいレポートクラスターに複製しました。レプリケーション用にセットアップした最初の可用性グループは問題なく問題なく機能しましたが、その後、はるかに大きなデータベース（合計3TBを超える）を備えた2番目の可用性グループに移動すると、かなり時間がかかり、5つのデータベースのうち2つが失敗しました。直接シードを使用するように分散型可用性グループを設定し、sys.dm_hadr_automatic_seedingテーブルを照会すると、current_stateがFAILEDとして示され、failure_state 2（SQLエラー）または21（シードチェックメッセージタイムアウト）が示されます。
この問題をトラブルシューティングするにはどうすればよいですか？
AlwaysOn Professionalブログには 直接シード の一般的なトラブルシューティング手順があり、シード中の圧縮を有効にするトレースフラグ9567に関する詳細も含まれていますが、SQLエラーまたはシードタイムアウトの詳細は見つかりませんでした。
以前は、大規模なデータベースで可用性グループに問題が発生する問題がありましたが、通常これは プライマリーから最新のトランザクションログをレプリカに対して適用する によって解決されます。
この場合、データベースはセカンダリ可用性グループにリカバリ中としてリストされていたため、プライマリから最新のトランザクションログバックアップを適用してから、データベースをセカンダリ可用性グループに参加させました。
--Restore transaction logs from primary and stay in recovery mode. Multiple backup files may need to be restored from oldest to newest.
RESTORE LOG stackoverflow from disk = '\\Backups\SQL\_Trans\StackOverflow_AG\StackOverflow\StackOverflow_LOG_20170810_175400.trn' WITH NORECOVERY;
ALTER DATABASE stackoverflow SET HADR AVAILABILITY GROUP = [StackOverflow_RAG];
ALTER DATABASE stackoverflow SET HADR RESUME;
これは、障害が発生したデータベースの両方で機能し、レプリケーションの問題を修正しました。これで、レポートクラスターにすべてのデータベースがプライマリ可用性グループから同期されました。
SQL Server 2016/2017にはまだ修正されていないバグがあります。CU2を使用するSP2でこの問題に対処してください。データベースが1GBと小さかったため、疑わしいトレースフラグ9567が解決策です。
以下のクエリのnumber_of_attemptsに注意してください。値は1です。直接シードを行う前に、数回の再試行を期待しますが、どこに設定するかわかりません。
USE [master];
SELECT TOP 100 * FROM sys.dm_hadr_automatic_seeding WHERE current_state = 'FAILED' ORDER BY start_time DESC;