使用者在 SQL 受控執行個體上起始的手動容錯移轉
適用於:Azure SQL 受控執行個體
本文說明如何手動容錯移轉 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 受控執行個體?。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應