分佈式可用性組直播失敗，failure_state SQL 錯誤，failure_state 2

我們剛剛開始設置分佈式可用性組，以將我們的生產數據庫複製到一個新的報告集群中。我們為複制設置的第一個可用性組執行良好，沒有任何問題，但是當我們轉移到具有更大數據庫（總共超過 3TB）的第二個可用性組時，它花費了更長的時間，並且 5 個數據庫中的兩個發生了故障。我們將分佈式可用性組設置為使用直接播種，並在查詢 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;

這適用於兩個失敗的數據庫並修復了複製問題。我們的報告集群現在擁有與主要可用性組保持同步的所有數據庫：

引用自：https://dba.stackexchange.com/questions/183208