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

適用于:Azure SQL 受控執行個體

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

注意

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

使用手動容錯移轉的時機

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

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

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

注意

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

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

需要 Azure RBAC 權限

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

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

使用 PowerShell

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

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

$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

使用下列 PS 命令以容錯移轉讀取次要節點,這僅適用於 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 呼叫來初始容錯移轉可以完成此功能。 如需詳細資料,請參閱受控執行個體 - 容錯移轉 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

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

注意

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

重要

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

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

後續步驟