執行 Always On 可用性群組的強制手動故障轉移 (SQL Server)

發行項
2025-03-05

適用於：SQL Server

本主題說明如何使用 SQL Server Management Studio、Transact-SQL 或 SQL Server 中的 PowerShell，在可能遺失資料的情況下針對 Always On 可用性群組執行強制容錯移轉。強制容錯移轉是一種手動容錯移轉形式，嚴格限於當已規劃的手動容錯移轉不可行時用於災難恢復。如果您強制容錯移轉至非同步的次要複本，有些資料可能會遺失。因此，強烈建議您只有在必須立即還原可用性群組服務且願意承擔資料遺失風險的情況下，才進行強制容錯移轉。

強制容錯移轉之後，可用性群組故障轉移的對象成為新的主要複本。剩餘的次要副本中的輔助資料庫會暫停，且必須手動恢復。當之前的主要複本重新變得可用時，它會轉換為次要角色，導致之前的主要資料庫變成次要資料庫並進入 SUSPENDED 狀態。在繼續執行給定的次要資料庫之前，您或許可以從該資料庫復原遺失的資料。不過須注意，只要有任何次要資料庫暫停，給定主要資料庫上的交易記錄截斷就會延遲。

重要

在次要資料庫恢復之前，將不會進行與主要資料庫的資料同步處理。如需重新啟用次要資料庫的資訊，請參閱本文稍後的後續操作：強制容錯移轉後的重要工作。

在下列緊急情況中，必須執行強制故障切換：

在 WSFC 叢集上強制進行仲裁之後 (「強制仲裁」(Forced Quorum) )，您需要強制容錯移轉每個可用性群組 (可能會遺失資料)。強制容錯移轉是必要的，因為 WSFC 叢集值的真實狀態可能已遺失。不過，如果您能夠在強制仲裁之前，在曾經是主要複本的伺服器執行個體上強制容錯移轉，或容錯移轉至在強制仲裁之前已同步的次要複本，則可以避免資料遺失。如需詳細資訊，請參閱本主題稍後的避免在強制仲裁之後遺失資料的可能方式。

重要

如果仲裁是通過自然方式而不是強制方式重新取得的，則可用性副本會正常地進行復原。如果在重新取得仲裁之後主要複本仍然無法使用，您可以執行規劃的手動容錯移轉至同步處理的次要複本。

如需強制仲裁的資訊，請參閱透過強制仲裁 (SQL Server) 的災害復原資訊。如需瞭解為什麼在強制仲裁後需要進行強制容錯移轉，請參閱容錯移轉及容錯移轉模式 (AlwaysOn 可用性群組)。
如果在 WSFC 叢集具有良好仲裁的情況下主要複本變得無法使用，您可以強制將其容錯移轉（可能會導致資料遺失）到任何角色為 SECONDARY 或 RESOLVING 狀態的複本。如有可能，在主要複本失效時，強制故障轉移至已同步完成的次要複本。

提示

當 WSFC 叢集擁有狀況良好的仲裁時，如果您在已同步處理的次要複本上發出強制容錯移轉命令，則複本會實際執行規劃的手動容錯移轉。

注意

如需強制容錯移轉之必要條件和建議的詳細資訊，以及使用強制容錯移轉從重大錯誤復原的範例案例，請參閱本主題稍後的範例案例：使用強制容錯移轉從重大錯誤復原。

限制事項

唯一無法進行強制故障轉移的情況，是當 Windows Server 容錯移轉叢集 (WSFC) 缺少法定票數時。
在可用性群組的被迫故障轉移期間，可能會發生資料遺失。此外，如果主要複本在您起始強制容錯移轉時正在執行，用戶端可能仍然會連接至先前的主要資料庫。因此，我們強烈建議您僅在主要副本無法運行並且您願意承擔遺失資料的風險，以便恢復可用性群組中資料庫的存取時，才進行強制容錯移轉。
當次要資料庫處於 REVERTING 或 INITIALIZING 狀態時，強制故障轉移會導致資料庫無法作為主要資料庫啟動。如果資料庫處於 INITIALIZING 狀態，您需要從資料庫備份套用遺失的記錄檔記錄，或從頭完全還原資料庫。如果資料庫處於 REVERTING 狀態，您就必須從備份完全還原資料庫。
只要容錯移轉目標接受了命令，就會傳回容錯移轉命令。不過，在可用性群組完成容錯移轉之後，會以非同步方式復原資料庫。
容錯移轉時，可能不會保留可用性群組內跨資料庫的一致性。

注意

跨資料庫和分散式交易的支援會因 SQL Server 和作業系統版本而不同。如需詳細資訊，請參閱適用於 Always On 可用性群組和資料庫鏡像的跨資料庫交易和分散式交易 (SQL Server)。

必要條件

WSFC 叢集擁有仲裁功能。若叢集缺少仲裁，請參閱藉由強制仲裁的 WSFC 災害復原 (SQL Server)。
您必須能夠連接到裝載複本的伺服器執行個體，而該複本的角色狀態為 SECONDARY 或 RESOLVING。

建議

主要複本仍在運行時，請勿強制進行故障切換。
可能的話，只強制容錯移轉至次要資料庫為 NOT SYNCHRONIZED、SYNCHRONIZED 或 SYNCHRONIZING 狀態的容錯移轉目標。如需有關次要資料庫處於初始化或還原狀態時強制容錯移轉之含意的資訊，請參閱此主題中前面的限制事項。
相較於主要資料庫，給定次要資料庫在不同非同步認可次要複本上的延遲通常應該相似。不過，在強制容錯移轉時，資料遺失可能會是一個嚴重的問題。因此，請花點時間決定不同次要複本上資料庫副本的相對延遲。若要確定哪一個指定的次要資料庫副本具有最小延遲，請比較它們的日誌結尾 LSN。記錄檔結束 LSN 越高，表示延遲越少。

提示

若要比較記錄檔結尾 LSN，請依次連接到每個線上次要複本，並查詢 sys.dm_hadr_database_replica_states，以獲取各本機次要資料庫的 end_of_log_lsn 值。然後，比較每個資料庫不同副本的日誌檔結尾 LSN。請注意，不同的資料庫在不同的次要複本上可能擁有最高的 LSN。在此情況下，最適合的容錯移轉目標取決於您在不同資料庫中之資料的相對重要性。也就是說，在這些資料庫中，您想要將哪些資料遺失的可能性降到最低？
如果用戶端能夠連接到原始的主要複本，強制容錯移轉會產生核心分裂行為的某些風險。在您強制容錯移轉之前，強烈建議您防止用戶端存取原始的主要複本。否則，在強制故障轉移之後，原始的主要資料庫和目前的主要資料庫可能會各自獨立更新。

避免在強制仲裁之後遺失資料的可能方式

在某些失敗情況下失去仲裁之後，您可以避免資料遺失，如下所示：

如果原始主要複本上線時

如果仲裁遺失且強制 WSFC 仲裁還原裝載可用性群組主要複本的叢集節點，則您可以防止這個可用性群組的資料遺失。連接到主要複本並執行強制容錯移轉 (FAILOVER_ALLOW_DATA_LOSS)。這樣會讓主要複本重新上線。由於您執行強制容錯移轉至原始主要複本，因此資料不會遺失。
如果同步提交的同步次要複本上線

如果仲裁失效並強制 WSFC 仲裁以還原裝載可用性群組之已同步次要複本的叢集節點，那麼您應能夠防止這個可用性群組的資料遺失。如果還原的節點在遺失仲裁時處於運作狀態，您可以藉由查詢 sys.dm_hadr_database_replica_cluster_states 動態管理檢視中的 is_failover_ready 資料行，查明某個特定資料庫是否可能發生資料遺失。例如，針對名為 sql108w2k8r22的伺服器執行個體，發出下列查詢：
```
SELECT * FROM sys.dm_hadr_database_replica_cluster_states  
   WHERE replica_id=(SELECT replica_id FROM sys.availability_replicas   
      WHERE replica_server_name ='sql108w2k8r22')  
```
警告

如果還原的節點在遺失仲裁時並未運行，則 is_failover_ready 可能不會準確反映主要複本離線時叢集的實際狀態。因此，is_failover_ready 值只有在發生故障時主機節點存在的情況下才有效。如需詳細資訊，請參閱容錯移轉及容錯移轉模式 (Always On 可用性群組) 中的＜為什麼需要在強制仲裁之後強制容錯移轉＞。

如果 is_failover_ready = 1，資料庫在叢集中會標示為已同步處理，並且準備好進行容錯移轉。如果在某個次要複本的每個資料庫上 is_failover_ready = 1，您可以執行強制容錯移轉 (FORCE_FAILOVER_ALLOW_DATA_LOSS)，而這個操作不會導致資料遺失。同步的次要複本作為主要角色上線，也就是成為新的主要複本，而且所有資料都保持不變。

如果 is_failover_ready = 0，則資料庫在叢集中不會標記為已同步，並且尚未準備好進行計劃的手動容錯移轉。如果您強制將故障移轉至主機的次要複本，則此資料庫中的資料將會遺失。

注意

當您強制容錯移轉至次要複本時，遺失的資料量將取決於容錯移轉目標落後於主要複本的距離。不幸的是，當 WSFC 叢集缺少法定人數仲裁或已強制法定人數仲裁時，您就無法評估可能遺失的資料量。不過請注意，一旦 WSFC 叢集重新取得狀況良好的法定人數，您就可以開始追蹤可能的資料遺失。如需詳細資訊，請參閱容錯移轉及容錯移轉模式 (Always On 可用性群組) 中的「追蹤可能的資料遺失」。

權限

需要具備以下任一權限：可用性群組的 ALTER AVAILABILITY GROUP 權限、CONTROL AVAILABILITY GROUP 權限、ALTER ANY AVAILABILITY GROUP 權限或 CONTROL SERVER 權限。

使用 SQL Server Management Studio

若要強制容錯移轉 (可能會遺失資料)

於 [物件總管] 中，連接到伺服器執行個體，該執行個體的複本其角色在需要進行容錯移轉的可用性群組中為 SECONDARY 或 RESOLVING 狀態，然後展開伺服器樹狀目錄。
依序展開 [Always On 高可用性] 節點和 [可用性群組] 節點。
以滑鼠右鍵按一下要容錯移轉的可用性群組，然後選取 [容錯移轉] 命令。
這會啟動「故障移轉可用性群組精靈」。如需詳細資訊，請參閱使用容錯移轉可用性群組精靈 (SQL Server Management Studio)。
強制可用性群組容錯移轉之後，完成必要的後續追蹤步驟。如需詳細資訊，請參閱本主題稍後的後續操作：強制容錯移轉後的重要工作。

使用 TRANSACT-SQL

若要強制故障轉移 (可能會遺失資料)

連線到裝載複本的伺服器執行個體，而在需要容錯移轉的可用性群組中，複本的角色為 SECONDARY 或 RESOLVING 狀態。
使用 ALTER AVAILABILITY GROUP 語句，如下所示：

變更可用性群組 group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

其中 <群組名稱> 是可用性群組的名稱。

下列範例會將 AccountsAG 可用性群組強制故障轉移至本機次要複本。
```
ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
```
強制可用性群組故障移轉之後，完成必要的後續步驟。如需詳細資訊，請參閱本主題稍後的後續操作：強制容錯移轉後的重要工作。

使用 PowerShell

若要強制執行故障移轉 (資料可能會遺失)

將目錄 (cd) 變更為裝載複本的伺服器執行個體，而其角色在需要容錯移轉的可用性群組中具有 SECONDARY 或 RESOLVING 狀態。
以下列其中一種形式，搭配 AllowDataLoss 參數使用 Switch-SqlAvailabilityGroup Cmdlet：
- -允許資料遺失
  
  依預設， -AllowDataLoss 參數會使 Switch-SqlAvailabilityGroup 提示您注意強制容錯移轉可能會導致未認可交易遺失，並要求確認。若要繼續，請輸入 Y；若要取消操作，請輸入 N。
  
  以下範例會將可用性群組 MyAg 強制容錯移轉 (可能會遺失資料) 到伺服器執行個體名稱為 SecondaryServer\InstanceName 的次要複本。您將會收到確認此作業的提示。
```
Switch-SqlAvailabilityGroup `  
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
   -AllowDataLoss  
```
- -AllowDataLoss-Force
  
  若要在不確認的情況下起始強制容錯移轉，請同時指定 -AllowDataLoss 和 -Force 參數。如果您要在指令碼中加入命令，並在沒有使用者介入的情況之下執行它，這相當實用。使用 -Force 選項時請小心，因為強制故障轉移可能會導致參與 SQL Server 可用性群組的資料庫中的資料遺失。
  
  以下範例會將可用性群組 MyAg 強制容錯移轉（可能會遺失資料）到名稱為 SecondaryServer\InstanceName 的伺服器執行個體。 -Force 選項會隱藏此作業的確認。
```
Switch-SqlAvailabilityGroup `  
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
   -AllowDataLoss -Force  
```
注意

若要檢視 Cmdlet 的語法，請在 SQL Server PowerShell 環境中使用 Get-Help Cmdlet。如需詳細資訊，請參閱 Get Help SQL Server PowerShell。
強制可用性群組容錯移轉之後，完成必要的後續追蹤步驟。如需詳細資訊，請參閱本主題稍後部分的後續操作：強制容錯移轉後的關鍵任務。

若要設定和使用 SQL Server PowerShell 提供者

SQL Server PowerShell 提供者

強制故障切換後的後續重要任務

在強制容錯移轉之後，您切換至的次要複本會成為新的主要複本。不過，若要讓該可用性複本可供用戶端存取，您可能需要重新設定 WSFC 仲裁，或調整可用性群組的可用性模式組態，如下所示：
- 如果您從自動容錯移轉組外部進行容錯移轉：請調整 WSFC 節點的仲裁投票，以反映您的新可用性群組設定。如果裝置目標次要複本的 WSFC 節點沒有 WSFC 仲裁投票，可能需要強制 WSFC 仲裁。
  
  注意
  
  只有當將兩個可用性複本（包括之前的主要複本）配置為同步認可模式並啟用自動容錯移轉時，自動容錯移轉組才會存在。
  
  若要調整法定人數投票
- 如果您容錯移轉到同步認可容錯移轉組外部：建議您考慮針對新的主要複本和剩餘的次要複本，調整可用性模式與容錯移轉模式，以反映您所需的同步認可及自動容錯移轉設定。
  
  注意
  
  只有在目前的主要複本設定成同步認可模式，同步認可容錯移轉組才會存在。
  
  若要更改可用性模式與故障移轉模式
  - 變更可用性複本的可用性模式 (SQL Server)
  - 變更可用性複本的容錯移轉模式 (SQL Server)
強制容錯移轉之後，就會暫停所有次要資料庫。這包括舊的主要資料庫，在舊的主要複本再次上線之後會發現它現在是次要複本。您必須在每個次要複本上對每個暫停的資料庫個別手動操作恢復。

當次要資料庫在暫停後繼續運行時，會開始與對應主要資料庫進行資料同步。次要資料庫會回滾在新的主要資料庫上從未提交過的任何記錄檔記錄。因此，如果您擔心主要資料庫在容錯移轉後可能發生資料遺失，應該嘗試在其中一個同步認可的次要資料庫上的暫停資料庫建立資料庫快照。

重要

只要有任何次要資料庫暫停，主要資料庫上的交易記錄截斷就會延遲。只要任何本機資料庫持續暫停，同步寫入次要副本的同步狀態就無法轉為健康。

若要建立資料庫快照
- 建立資料庫快照集 (Transact-SQL)
重新啟動可用性資料庫
- 繼續可用性資料庫 (SQL Server)
警告

在恢復所有次要資料庫之後，請等待下一個容錯移轉目標上的每個次要資料庫進入 SYNCHRONIZING 狀態，然後再嘗試容錯移轉群組。如果有任何資料庫尚未同步，該資料庫將無法作為主要資料庫上線，並且要重新建立資料庫的同步可能需要還原交易記錄、還原完整資料庫備份，或者回切到先前的主複本。
如果失敗的可用性複本無法返回可用性群組，或返回的時間太晚，無法讓您延遲新主要資料庫上的交易日誌截斷，請考慮將失敗的複本從可用性群組中移除，以避免記錄檔的磁碟空間用盡。

移除次要複本
- 將次要複本從可用性群組移除 (SQL Server)
如果您在強制容錯移轉之後進行一個或多個額外的強制容錯移轉，請在此系列中每一個額外的強制容錯移轉之後執行記錄備份。如需了解此原因的相關資訊，請參閱容錯移轉及容錯移轉模式 (Always On 可用性群組) 中的＜強制手動容錯移轉 (可能會遺失資料)＞一節裡的＜強制容錯移轉的風險＞。

若要執行記錄備份
- 備份交易記錄 (SQL Server)

範例情境：使用強制故障轉移從災難性故障復原

如果主要複本失敗且沒有可用的已同步次要複本，則強制可用性群組進行容錯移轉可能會是適當的反應。強制容錯移轉是否恰當取決於：(1) 您是否預期主要複本離線的時間超過服務等級合約 (SLA) 容忍範圍，以及 (2) 您是否願意承擔資料可能遺失的風險，而讓主要資料庫盡快恢復可用。如果您決定可用性群組需要強制容錯移轉，實際的強制容錯移轉只不過是多步驟程序中的一個步驟。

為了說明使用強制故障移轉從重大錯誤復原所需的步驟，本主題會介紹一個可能的災害復原案例。範例情境考慮的可用性組，其原始拓樸結構包括一個主要資料中心，該中心主控三個同步認可的可用性複本，其中包括一個主要複本，及一個遠端資料中心，該中心主控兩個非同步認可的次要複本。下圖說明此範例可用性群組的原始拓撲。可用性群組是由多重子網路 WSFC 叢集所主控，其中三個節點位於主要資料中心 (節點 01、 節點 02和 節點 03)，兩個位於遠端資料中心 (節點 04 和 節點 05)。

可用性群組的原始拓撲

主要資料中心意外關閉。其三個可用性複本離線，而且其資料庫變成不可用。下圖說明此錯誤對可用性群組拓撲的影響。

主要資料中心故障後的拓撲

資料庫管理員 (DBA) 判斷可能的最佳回應是強制可用性群組容錯移轉至其中一個遠端非同步認可次要複本。此範例說明強制可用性群組容錯移轉至遠端複本，以及最後恢復可用性群組的原始拓撲所包含的一般步驟。

這裡顯示的錯誤回應包括兩個階段：

回應主要資料中心的災難性故障
讓可用性群組恢復其原始拓撲

回應主要資料中心的災難性故障

下圖說明為了回應主要資料中心的重大錯誤，在遠端資料中心執行的一系列動作。

回應主要資料中心失敗的步驟

此圖中的階段表示以下步驟：

步驟	動作	連結
1.	DBA 或網路管理員確認 WSFC 叢集擁有狀況良好的仲裁。在此範例中，需要強制法定人數。	WSFC 仲裁模式和投票設定 (SQL Server) 透過強制法定人數進行 WSFC 災害復原 (SQL Server)
2.	DBA 連接到延遲最低的伺服器實例（在節點 04上），並進行強制手動故障移轉。強制故障轉移會將此次要複本轉換成主要複本，並且暫停其餘次要複本上的次要資料庫（於節點 05上）。	sys.dm_hadr_database_replica_states (Transact-SQL) (查詢 end_of_log_lsn 資料行。如需詳細資訊，請參閱本主題稍早提到的建議)。
3.	DBA 手動恢復在剩餘次要複本上的每個次要資料庫。	恢復可用性資料庫 (SQL Server)

讓可用性群組恢復其原始拓撲

下圖說明主要資料中心再次上線且 WSFC 節點重新建立與 WSFC 叢集的通訊之後，將可用性群組恢復為原始拓撲的一系列動作。

重要

如果 WSFC 叢集的仲裁設定已被強制，如果下列兩項條件都存在，離線節點在重新啟動時可能會形成新的仲裁：(a) 強制仲裁集中的任何節點之間都沒有網路連線，且 (b) 重新啟動的節點占據叢集節點的大多數。這樣會導致「核心分裂」的情況，這種情況下可用性群組會擁有兩個獨立的主要複本，每個資料中心各擁有一個。在強制法定人數以建立少數法定人數集之前，請參閱透過強制法定人數執行 WSFC 災害復原 (SQL Server)。

將群組傳回至其原始拓撲的步驟

此圖中的步驟會指出下列步驟：

	步驟	連結
1.	主要資料中心的節點再次上線，並且重新建立與 WSFC 叢集之間的通訊。其可用性複本會以暫停資料庫的次要複本來線，DBA 需要盡快手動恢復每個資料庫。	恢復 SQL Server 的可用性資料庫功能提示：如果您擔心容錯移轉後的主要資料庫可能會遺失資料，就應該嘗試在其中一個同步認可的次要資料庫上，建立暫停資料庫的資料庫快照集。務必記得，只要有任何次要資料庫暫停，主要資料庫上的交易記錄截斷就會延遲。另外，只要任何本機資料庫持續暫停狀態，同步認可次要複本的同步健全狀態就無法轉換成 HEALTHY。
2.	一旦資料庫恢復，DBA 會暫時將新的主要副本變更為同步認可模式。這包含兩個步驟： 1) 將一個離線可用性副本更改為非同步提交模式。 2) 將新的主要副本變更為同步認可模式。注意: 此步驟使恢復同步提交的次要資料庫達到 SYNCHRONIZED 狀態。	變更可用性複本的可用性模式 (SQL Server)
3.	一旦節點 03 (原始主要複本) 上的同步提交次要複本進入 HEALTHY 同步狀態，資料庫管理員就會執行計劃中的手動故障轉移到該複本，使其再次成為主要複本。節點 04 上的複本會恢復為次要複本。	sys.dm_hadr_database_replica_states (Transact-SQL) 使用 AlwaysOn 原則檢視可用性群組的健全狀況 (SQL Server) 執行可用性群組的計劃手動故障轉移 (SQL Server)
4.	DBA 連接到新的主副本，然後： 1) 將先前的主要副本 (位於遠端中心) 變更回非同步認可模式。 2) 將主要資料中心中的非同步提交次要複本切換回同步提交模式。	變更可用性複本的可用性模式 (SQL Server)

另請參閱

AlwaysOn 可用性群組概觀 (SQL Server)
可用性模式 (AlwaysOn 可用性群組)
故障轉移及故障轉移模式 (Always On 可用性群組)
關於可用性複本的用戶端連接存取 (SQL Server)
監視可用性群組 (SQL Server)
Windows Server 容錯移轉叢集 (WSFC) 與 SQL Server

共用方式為