管理實例連接最佳做法 - Azure SQL 受控執行個體

適用於：Azure SQL 受控執行個體

本文說明使用 受控執行個體 鏈接 在 Azure SQL 受控執行個體 與你的 SQL Server 實例之間進行資料複製的最佳實務。 連結提供連結副本間近乎即時的資料複製。

定期進行記錄備份

在建立連結前，特別是對於大型資料庫或多資料庫連結模式的多個資料庫，應在支援的 SQL Server 建置中使用追蹤旗標 12381，以防止在做種時過早截斷日誌。 在標記啟用時，日誌備份可以繼續，但保留的日誌記錄不會變得可重複使用。 監控記錄檔使用量、增長率及可用磁碟空間，並在所有正在建立的連結完成植入後立即停用該旗標。 SQL 受管理執行個體 錯誤記錄中出現的植入錯誤 1408 或 1412，可能表示記錄過早截斷。 在重新建立連結前，請先閱讀連結的故障排除指引。

當 SQL Server 是主要伺服器時，只要支援的建置中啟用追蹤旗標 12381，你可以在做種時繼續交易日誌備份。 如果你為了避免過早截斷而暫停日誌備份，請在初始播種結束後恢復備份。 如果您尚未開始進行交易記錄備份，請在初始植入完成後執行第一次交易記錄備份。 所有正在建立的連結都完成植入後，如果您已啟用該旗標，請停用該旗標，並在 SQL Server 仍為主要資料庫時定期進行SQL Server 交易記錄備份。

連結功能利用基於 Always On 可用性群組的 分散式可用性群組 技術來複製資料。 分散式可用性群組資料複製是基於交易日誌記錄的複製。 主要的 SQL Server 實例無法截斷資料庫中的任何交易記錄檔記錄，直到它們被複製到次要副本的資料庫。 若網路連線問題導致交易日誌記錄複製變慢或阻塞，日誌檔案會在主實例上持續成長。 工作負載強度與網路速度決定成長速度。 如果網路連線中斷持續且主實例工作負載過重，日誌檔案可能會佔用所有可用儲存空間。

定期進行交易記錄檔備份，可在沒有其他因素阻止截斷時，讓非使用中的記錄檔記錄得以重複使用。 他們不會釋出由追蹤標誌 12381、複製或活躍交易所保留的紀錄，也不會縮小實體日誌檔。 當 SQL 受管理執行個體 為主要時，無需額外操作，因為日誌備份已經自動進行。 根據你的工作量排定定期的 SQL Server 日誌備份，並監控日誌使用率及可用磁碟空間。

你可以使用 Transact-SQL（T-SQL）腳本來備份日誌檔案，就像本節提供的範例一樣。 請將範例指令碼中的預留位置取代為您的資料庫名稱、備份檔案名稱、備份檔案的路徑，以及描述。

要備份你的交易日誌，請在 SQL Server 上使用以下範例 Transact-SQL（T-SQL）腳本：

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

請使用以下 Transact-SQL（T-SQL） 指令檢查資料庫在 SQL Server 上使用的日誌間隔：

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

範例資料庫 tpcc 的查詢輸出如下所示：

命令結果的螢幕擷取畫面，其中顯示使用的記錄檔大小和空間

在此範例中，資料庫已使用 76% 的可用記錄，且絕對記錄檔大小約為 27 GB (27，971 MB)。 動作的閾值會根據您的工作負載而有所不同。 在前一個例子中，交易日誌大小與使用百分比通常表示你應該備份交易日誌以截斷日誌檔案並釋放空間，或是更頻繁地備份日誌。 這也可能表示開放的交易可能會阻止交易記錄的截斷。 欲了解更多關於SQL Server中交易日誌故障排除的資訊，請參見 Troubleshoot a Full Transaction Log （SQL Server Error 9002）。 欲了解更多關於Azure SQL 受控執行個體中交易日誌故障排除的資訊，請參見 Troubleshoot transaction log error with Azure SQL 受控執行個體。

注意

參與連結時，SQL 受管理執行個體 會自動備份完整且交易日誌的備份，不論它是不是主要副本。 不進行差異備份，這可能會導致還原時間更長。

比對複本之間的效能容量

使用連結功能時，請在 SQL Server 與 SQL 受管理執行個體 之間的效能容量間進行匹配。 這種匹配能幫助你避免當次要副本無法跟上主副本的複製，或在故障轉移後產生的效能問題。 效能容量包括 CPU 核心（在 Azure 中稱為 vCore）、記憶體及 I/O 吞吐量。

你可以透過檢查次要副本的重做佇列大小來監控複寫的效能。 重做佇列大小顯示次要副本上等待重做的日誌記錄數量。 持續高的重做佇列大小顯示次要副本始終無法跟上主要副本。 您可以透過下列方式檢查重做佇列大小：

  • 主要複本上的動態管理檢視 redo_queue_size 中的 值。
  • 在主要複本上的 InstanceRedoLagReplicationSeconds 中的 值。

如果重做佇列大小始終較高，請考慮增加次要複本上的資源。

監控複製延遲

監控複製延遲有助於判斷次要副本與主要副本同步的速度。 大幅度差異表示次要副本難以跟上主要副本，這通常是因為兩個實例間連結的網路吞吐量緩慢、兩副本間資源分配不匹配，或主要副本的工作負載過高所致。

監控複製延遲在執行計畫性故障轉移時尤其重要，因為計畫性故障轉移需要次要副本與主要副本完全同步，才能執行故障轉移。 如果複製延遲較高，故障切換可能需要更長時間完成，有時甚至可能會失敗。

請在 SQL Server 和 SQL 受管理執行個體 上使用以下 T-SQL 查詢，來監控副本間的複寫延遲：

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

輪換憑證

你可能需要手動輪換用來保護 SQL Server 上資料庫鏡像端點的憑證。 由於服務會管理並自動更換用於保護資料庫鏡像端點的憑證，SQL 受管理執行個體你不需要手動更換它。

SQL Server

你用來保護 SQL Server 上資料庫鏡像端點的憑證可能會過期。 如果憑證過期，可能會導致連結品質下降。 為避免此問題，請在證書到期前 輪換 。

請使用以下 Transact-SQL（T-SQL） 指令檢查目前憑證的有效期限：

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

如果你的憑證快到期或已經過期，請 建立新憑證，然後修改現有端點以 取代現有憑證。

在你設定端點使用新憑證後，就可以 丟棄 過期的憑證。

SQL 受控執行個體

SQL 受管理執行個體 上的資料庫鏡像端點憑證會定期自動輪替。 你不需要監控資料庫鏡像端SQL 受管理執行個體點憑證的到期日，只要能成功驗證SQL Server的憑證鏈即可。

在 SQL Server 上驗證憑證鏈

注意

定期驗證憑證鏈中現有連結的狀況，或排除連結退化問題。 如果你正在設定新連結或最近完成了 節中的步驟，請從 SQL 受管理執行個體 取得憑證公鑰並匯入到 SQL Server 以及 將Azure受信任的根憑證授權金鑰匯入 SQL Server，請跳過此節。

憑證鏈的問題可能會破壞連結。 為避免此問題，定期驗證SQL Server的憑證鏈。

以下情境可能導致 SQL Server 上的憑證鏈出現問題：

  • SQL 受管理執行個體 上的憑證排程輪替。
  • SQL Server 上憑證的無意或意外變更，例如遺失或更改用於保護資料庫鏡像端點的憑證。

首先，透過替換 certificate_id 的值，確定匯入 MI 端點憑證的 <ManagedInstanceFQDN>，然後對 SQL Server 執行以下查詢：

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

接著，透過替換前一查詢結果中的 <certificate_id> 值來驗證憑證，然後對 SQL Server 執行以下查詢：

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

回應 Commands completed successfully. Completion time: ... 表示 MI 端點憑證已成功驗證。

這很重要

儲存程序 sp_validate_certificate_ca_chain 依賴主機作業系統服務執行憑證驗證，這可能涉及線上憑證撤銷檢查。 如果主機作業系統未設定為存取網際網路，即使憑證鏈有效，執行也會失敗。

若遇到錯誤，最可靠的緩解方法是先刪除所有在取得 SQL 受管理執行個體 的憑證公鑰並匯入至 SQL Server及匯入 Azure 信任的根憑證授權金鑰至 SQL Server區段中建立的憑證，然後再重新匯入。

新增啟動追蹤旗標

在 SQL Server 中，有兩個追蹤旗標（-T1800 和 -T9567），當它們作為啟動參數時，可以優化透過連結進行資料複製的效能。 若要深入了解，請參閱啟用啟動追蹤旗標 (英文)。

使用同步提交時要小心

該連結的預設提交模式為非同步。 雖然可以將提交模式改為同步，但不建議也不必這麼做，以避免潛在的資料遺失。

在計畫中的連結故障轉移期間，複寫會暫時切換為同步提交模式，直到故障轉移完成。 故障轉移後，提交模式會切回非同步，即使在故障轉移前已明確設定為同步提交模式。

對此連結使用同步提交模式可能會影響主要副本的效能，尤其是在副本之間的網路延遲很高時。 在同步提交模式下，主副本的交易必須等待確認交易日誌記錄已在次要副本上硬化後，才能在主副本上提交交易。 隨著網路延遲增加，等待時間會增加，可能導致交易回應時間增加並降低主副本的吞吐量。

相關內容

若要使用連結：

若要深入了解連結：

針對其他複寫和移轉案例，請考慮：

  • Last updated on