AlwaysOn 可用性組強制故障轉移
我可以請求您的意見嗎?
我在同步和輔助可讀模式下為我的數據庫設置了始終在可用性組上的 SQL 2012。我使用同步模式完成了故障轉移測試,它按預期執行。
使用非同步模式進行強制故障轉移測試後,是否需要重建舊的主數據庫?因為新主節點中的更改不會反映回來。數據庫狀態未同步…而不是同步…
感謝您的意見,因為我了解了這個概念。
謝謝
使用非同步模式進行強制故障轉移測試後,是否需要重建舊的主數據庫?
我不確定您所說的“重建”數據庫究竟是什麼意思,但如果數據庫仍處於工作狀態,那麼您不需要採取任何類似的操作。
通過執行強制故障轉移,您所看到的是設計使然。如果您執行強制故障轉移,您可能已故障轉移到未完全趕上的副本或與主副本處於同一時間點的副本。因此,數據從現在的主副本到輔助副本的移動被暫停,因此如果您現在位於“後面”的數據庫上,則可以進行手動干預。您所看到的這種行為是一件好事。
這個 BOL 參考解釋了這一切:
強制故障轉移後,所有輔助數據庫都將暫停。這包括以前的主數據庫,在以前的主副本重新聯機並發現它現在是輔助副本之後。您必須在每個輔助副本上單獨手動恢復每個掛起的數據庫。
當從數據庫恢復時,它會啟動與對應的主數據庫的數據同步。輔助數據庫回滾從未在新主數據庫上送出的任何日誌記錄。因此,如果您擔心故障轉移後主數據庫上可能的數據失去,您應該嘗試在同步送出輔助數據庫之一上的掛起數據庫上創建數據庫快照。
用於此的 T-SQL 將是:
alter database YourDatabaseName set hadr resume;
注意/警告/免責聲明:您確實需要做一些工作以確保您不會因恢復數據移動而導致數據失去。見上文,這可能是一個大問題。暫停數據移動的目的正是出於這個原因:手動確保您可以恢復盡可能多的數據。當您恢復數據移動時,這可能是不可逆轉的。當您在強制故障轉移後恢復數據移動時,您必須始終將“潛在的數據失去”一詞放在腦海中。