使用者在 SQL 受控執行個體上起始的手動容錯移轉

發行項
03/11/2024

本文說明如何手動容錯移轉 SQL 受控執行個體一般用途 (GP) 和業務關鍵 (BC) 服務層上的主要節點，以及如何僅手動容錯移轉 BC 服務層上的次要唯讀複本節點。

注意

本文與容錯移轉群組上的跨區域容錯移轉無關。

使用手動容錯移轉的時機

高可用性是 SQL 受控執行個體平台的基礎部分，可為您的資料庫應用程式提供透明的運作。針對 Azure 中使用 SQL 受控執行個體的所有應用程式，在節點降級或錯誤偵測時或是在一般每月軟體更新期間，從主要節點容錯移轉至次要節點都是預期會發生的情況。

基於下列一些原因，您可能會考慮在 SQL 受控執行個體上執行手動容錯移轉：

在部署至生產環境之前，測試應用程式的容錯移轉復原
測試端對端系統的自動容錯移轉時錯誤復原
測試容錯移轉對現有資料庫工作階段的影響
確認容錯移轉是否因網路延遲的變更而變更端對端效能
在一些查詢效能降低的情況下，手動容錯移轉有助於減輕效能問題。

注意

在部署至生產環境之前，確保您的應用程式具有容錯移轉復原功能，有助於降低生產環境中應用程式錯誤的風險，並且會為您的客戶提供應用程式可用性。透過使用 SQL 受控執行個體測試應用程式雲端整備程度的容錯移轉復原影片錄製，深入了解如何測試應用程式的雲端整備程度。

在 SQL 受控執行個體上起始手動容錯移轉

需要 Azure RBAC 權限

起始容錯移轉的使用者需要具有下列其中一個 Azure 角色：

「訂用帳戶擁有者」角色，或
SQL 受控執行個體參與者角色或
有下列權限的自訂角色：
- Microsoft.Sql/managedInstances/failover/action

使用 PowerShell

Az.Sql 的最小版本需要是 2.9.0 版。請考慮使用 Azure 入口網站中一律具有最新 PowerShell 版本的 Azure Cloud Shell。

必要條件是使用下列 PowerShell 指令碼來安裝所需的 Azure 模組。此外，請選取您想要容錯移轉的 SQL 受控執行個體所在的訂用帳戶。

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

搭配使用 PowerShell 命令 Invoke-AzSqlInstanceFailover 與下列範例，以起始主要節點的容錯移轉，這同時適用於 BC 和 GP 服務層。

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

使用下列 PowerShell 命令以容錯移轉讀取次要節點，這僅適用於 BC 服務層。

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

使用 CLI

確定已安裝最新 CLI 指令碼。

搭配使用 az sql mi 容錯移轉 CLI 命令與下列範例，以起始主要節點的容錯移轉，這同時適用於 BC 和 GP 服務層。

az sql mi failover -g myresourcegroup -n myinstancename

使用下列 CLI 命令以容錯移轉讀取次要節點，這僅適用於 BC 服務層。

az sql mi failover -g myresourcegroup -n myinstancename --replica-type ReadableSecondary

使用 REST API

如果進階使用者可能需要自動容錯移轉 SQL 受控執行個體以實作持續測試管線或自動化效能減緩器，則透過 API 呼叫來初始容錯移轉可以完成此功能。如需詳細資料，請參閱 SQL 受控執行個體 - 容錯移轉 REST API。

若要使用 REST API 呼叫來起始容錯移轉，請先使用您選擇的 API 用戶端來產生驗證權杖。產生的驗證權杖用作 API 要求標頭中的授權屬性，而且是必要項目。

下列程式碼是要呼叫的 API URI 範例：

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/managedInstances/{managedInstanceName}/failover?api-version=2019-06-01-preview

下列是需要在 API 呼叫中傳遞的屬性：

API 屬性	參數
subscriptionId	要部署受控執行個體的訂用帳戶識別碼
resourceGroupName	包含受控執行個體的資源群組
managedInstanceName	受控執行個體的名稱
replicaType	(選用) (Primary 或 ReadableSecondary)。這些參數代表要容錯移轉的複本類型：主要或可讀取次要複本。如果未指定，則預設會在主要複本上起始容錯移轉。
api-version	靜態值，目前必須為 "2019-06-01-preview"

API 回應會是下列兩者中的其中一種：

202 已接受
其中一個 400 要求錯誤。

您可以透過檢閱回應標頭中的 API 回應來追蹤作業狀態。如需詳細資訊，請參閱非同步 Azure 作業的狀態。

監視容錯移轉

若要監視使用者針對 BC 執行個體所起始的容錯移轉進度，請在 SQL 受控執行個體上您慣用的用戶端 (例如 SSMS) 中執行下列 T-SQL 查詢。它會讀取系統檢視 sys.dm_hadr_fabric_replica_states 以及執行個體上可用的報表複本。在起始手動容錯移轉之後，請重新整理相同的查詢。

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

在起始容錯移轉之前，您的輸出會指出 BC 服務層上目前的主要複本，而此服務層包含 Always On 可用性群組中的一個主要和三個次要複本。執行容錯移轉時，再次執行此查詢將需要指出主要節點的變更。

您將看不到與上方 BC 服務層輸出相同的 GP 服務層輸出。這是因為 GP 服務層只以單一節點為基礎。您可以使用替代 T-SQL 查詢，而此查詢顯示在 GP 服務層執行個體的節點上啟動 SQL 程序的時間：

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

在容錯移轉期間，用戶端連線短暫中斷 (通常會在一分鐘內穩定) 會指出容錯移轉執行，而不論服務層為何。

注意

容錯移轉程序的完成 (不是實際的短時間無法使用) 一次可能需要幾分鐘的時間來處理高強度工作負載。這是因為執行個體引擎會處理主要節點上的所有目前交易，並在可以容錯移轉之前放到次要節點上。

重要

使用者起始手動容錯移轉的功能限制為：

在相同的 SQL 受控執行個體上，每隔 15 分鐘可能會起始一 (1) 次容錯移轉。
針對 BC 執行個體，必須要有複本的仲裁，才能接受容錯移轉要求。
針對 BC 執行個體，無法指定要在哪個可讀取次要複本上起始容錯移轉。
除非自動備份系統完成新資料庫的第一個完整備份，否則將不允許容錯移轉。
如果已在進行資料庫還原，則不允許容錯移轉。

下一步

透過使用 SQL 受控執行個體測試應用程式雲端整備程度的容錯移轉復原影片錄製，深入了解如何測試應用程式的雲端整備程度。
深入了解受控執行個體的高可用性：Azure SQL 受控執行個體的高可用性。
如需概觀，請參閱什麼是 Azure SQL 受控執行個體？。