針對處於還原狀態的可用性群組資料庫進行疑難解答
本文可協助您針對處於還原狀態的可用性群組資料庫進行疑難解答。
什麼是還原狀態?
當輔助伺服器必須復原已套用的變更,才能與主伺服器重新同步時,就會發生還原狀態。
可用性群組主要和次要複本 () 在正常作業期間保持聯機狀態,因此主要復本的變更會主動與次要複本 (的) 同步處理。
在故障轉移期間,此聯機狀態會遭到嚴重移轉。 一旦新的主要復本上線之後,主要復本與次要復本之間的連線就會重新建立 () 。 在此初始連線狀態期間,會交涉一般恢復點,其中新的次要複本應該開始復原,使其與主要復原同步。
如果在故障轉移時執行大型交易,新的輔助資料庫記錄會在主要複本資料庫之前。 交涉的新一般恢復點會要求次要復本接收來自主要複本的頁面,使其處於可繼續同步處理的狀態。 還原程式也稱為「復原取消復原」。
還原程式原本就很慢、經常發生,而且通常幾乎不會注意到觸發還原狀態的小型交易。 當故障轉移中斷大型交易時,通常會注意到還原狀態,導致許多頁面從主要復本傳送至次要複本,以將次要複本資料庫還原為可復原的狀態。
可用性群組資料庫處於還原狀態的徵兆和效果
當資料庫在次要復本上處於還原狀態時,資料庫不會同步處理,因此不會收到來自主要復本的變更。 在主要復本上突然遺失資料庫可能會導致數據遺失。
Always On 儀錶板報告主要伺服器上未同步處理
故障轉移可用性群組之後,您可能會發現在故障轉移成功時,次要複本回報為未同步處理。 Always On 儀錶板會報告主要和次要上的 「未同步處理」和「還原」。
Always On 儀錶板報告主要伺服器上未同步處理 | Always On 次要復原儀錶板報告 |
---|---|
Always On DMV 報告主要伺服器上的 NOT SYNCHRONIZING
當您查詢下列 Always On 可用性群組 (AG) 動態管理檢視 (DMV) ,資料庫會處於 NOT SYNCHRONIZING 狀態。
SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar
JOIN sys.dm_hadr_database_replica_states drs
ON ar.replica_id=drs.replica_id
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id
當您在次要資料庫上查詢 DMV 時,可用性群組資料庫會處於 REVERTING 狀態。
只讀和報告工作負載無法存取輔助資料庫
輔助資料庫正在還原時,無法加以存取或查詢。 這些只讀工作負載已離線並中斷。 根據資料庫處於還原狀態的時間長度,如果這些工作負載是業務關鍵,可能需要將這些工作負載重新路由至另一個次要複本或主要複本。
如果您有只讀工作負載,例如路由至次要複本的報告工作負載,這些批次可能會失敗並出現訊息 922:
正在復原 Msg 922,層級 14,狀態 1,第 2 行資料庫 'agdb'。 等候復原完成。
嘗試以還原狀態登入次要複本資料庫的應用程式無法連線並引發錯誤 18456:
2023-01-26 13:01:13.100 登入錯誤:18456,嚴重性:14,狀態:38。 使用者 『<UserName>』 的 2023-01-26 13:01:13.100 登入失敗。 原因:無法開啟明確指定的資料庫 'agdb'。 [用戶端: <本機計算機>]
如果稽核失敗的登入,您也可以在 SQL Server 錯誤記錄檔中回報此錯誤。
估計還原狀態的剩餘時間
使用下列其中一種方法來估計還原狀態的剩餘時間:
使用 AlwaysOn_health XEvent 工作階段
AlwaysOn_health擴充事件診斷記錄檔具有hadr_trace_message事件,每五分鐘報告一次還原狀態進度。
使用 SQL Server Management Studio (SSMS) 物件總管 連線到次要複本,然後鑽研到 [管理]、[擴充事件] 和 [會話]。 以滑鼠右鍵按兩下 AlwaysOn_health 活動,然後選取 [監看實時數據]。 您應該會取得新的索引標籤視窗,報告還原作業的目前狀態。 狀態會每隔五分鐘透過 hadr_trace_message
事件報告一次,並報告還原作業的已完成百分比。
注意事項
擴充事件hadr_trace_message
已新增至 SQL Server 2019 和更新版本中的最新累積更新。 您必須執行最新的累積更新,才能在擴充事件會話中 AlwaysOn_health
觀察此擴充事件。
在預估還原完成時,次要復本上的 SQL Server 錯誤記錄檔沒有太大説明。 在下圖中,您可以在還原狀態下觀察從 10:08 到 11:03 ,但很少報告。 次要復本從主要復本接收到所有頁面之後,現在就可以復原在原始主要復本上執行且觸發還原狀態的交易。 復原會從 11:03 執行到 11:05。 復原完成之後,資料庫應該會開始與主要複本同步處理,並在輔助資料庫處於還原狀態時,趕上在主要複本上所做的所有變更。
使用 效能監視器 監視還原完成時間
使用性能計數器 SQL Server:D atabase Replica:Total Log Requiring Undo 和 SQL Server:D atabase Replica:Log Remaining for Undo 監視還原狀態進度,並選擇實例的可用性群組資料庫。 在下列螢幕快照的範例中, [需要復原的總記錄 檔] 會回報為 56.3 mb,而 [復 原的剩餘記錄 檔] 會緩時下降至 0 ,以報告還原進度。
除了等候之外,還有哪些其他選項?
Microsoft 建議您預估還原狀態完成的時間。
將次要復本新增至可用性群組
如果可用性群組中只有兩個複本,請盡可能新增另一個可提供高可用性和備援的次要複本,並在其他次要複本完成還原時主動與主要複本同步處理。
重要事項
請勿故障轉移至資料庫 () 處於還原狀態的複本。 這可能會導致無法使用的資料庫需要從備份還原。 請勿重新啟動次要複本實例,它不會加速此程式,而且可能會危害處於還原狀態的次要複本資料庫狀態。
如何解決失敗的唯讀工作負載
由於還原中的次要復本資料庫無法存取,因此只讀工作負載會失敗。 更新讀取意圖路由表,以將流量路由傳送回主要復本或其他次要複本,直到受影響的次要複本資料庫完成還原程序為止。
避免還原狀態 - 監視大型交易
如果您經常在計劃性故障轉移期間觀察到此狀態,請實作在故障轉移之前檢查大型交易的程式。 下列查詢會報告系統上任何開啟交易的交易開始時間和目前時間,並提供交易的輸入緩衝區。
SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應