如何針對 RDS for SQL Server 僅供讀取複本的延遲問題進行疑難排解？

簡短描述

使用 Amazon RDS for SQL Server 企業版可在相同區域內建立僅供讀取複本。資料複製採非同步處理，並使用永遠啟用 (Always-On) 技術將主執行個體中的資料複製到複本執行個體。RDS for SQL Server 不會干預來源資料庫執行個體，及其僅供讀取複本之間複本延遲過久的情形，也不會將其縮短。

解決方案

1.    使用 Amazon CloudWatch 檢查主執行個體和複本執行個體上的資源使用率。使用增強型監控和效能洞見功能精細地檢查資源使用情況。

主執行個體和複本執行個體所用指標的重要考量事項：

• 請確定 CPU 使用率未受到節流調控。如果您執行的是高載執行個體類別，則請確保 CPU 積分可用，或是正在無限制模式下執行。
• 確定有足夠的可用記憶體。亦請確定 ReadiOps 和 WriteIOPS 已達到佈建的限值。如果使用的是 GP2 磁碟區，請驗證是否有足夠的爆量餘額可用。如需詳細資訊，請參閱如何對 RDS for SQL Server 執行個體可用記憶體不足的問題進行疑難排解？
• 確定 ReadThroughput 和 WriteThroughput 皆未達執行個體類別限值。

2.    最佳的實務做法是使用相同的執行個體類別、儲存類型和 IOPS 數目來建立主執行個體與複本執行個體。這樣可避免複本因為複本執行個體缺少資源而造成延遲。此外，視工作負載而定，如果僅供讀取複本的使用量比主執行個體低很多，則可以縱向擴展僅供讀取複本或縮減規模。

3.    指定複本延遲開始變長的時間範圍，然後執行下列操作：

根據複本開始延遲的時間，檢查主執行個體上的 WriteIOPS、WriteThroughput、NetworkReceiveThroughput 和 NetworkTrasmitThroughput 等指標。判斷是否因寫入活動而造成延遲。檢查僅供讀取複本同一時段內的同一批指標。

檢查主要執行個體上是否有長時間執行的交易。以下是作用中交易之檢查狀態的查詢範例：

SELECT * FROM sys.sysprocesses WHERE open_tran = 1;

4.    在複本執行個體上，檢查是否有任何重大的鎖定等待或鎖死。如果 Select 和 DDL/DML 交易之間發生鎖死並造成交易延遲，就會記錄在主要執行個體的日誌中。

以下是檢查封鎖的查詢範例：

SELECT * FROM sys.sysprocesses WHERE blocked > 0;

5.    查詢檢查複本延遲和複本延遲上限。

複本延遲

SELECT AR.replica_server_name
     , DB_NAME (ARS.database_id) 'database_name'
     , AR.availability_mode_desc
     , ARS.synchronization_health_desc
     , ARS.last_hardened_lsn
     , ARS.last_redone_lsn
     , ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;

確認僅供讀取複本上的「last_hardened_lsn」值正在不斷增加。

複本延遲上限

SQL Server 的 ReplicaLag 指標代表資料庫的延遲上限 (以秒為單位)。例如，如果您的兩個資料庫分別延遲 5 秒和 10 秒，則 ReplicaLag 為 10 秒。ReplicaLag 指標會傳回下列查詢的值。在主要執行個體上執行查詢。

select max(secondary_lag_seconds) max_lag  from sys.dm_hadr_database_replica_states;

6.    啟動僅供讀取複本建立功能後，會拍攝主要執行個體的快照，然後透過還原此快照的方式來建立僅供讀取複本執行個體。系統會重新顯示交易日誌，藉此將資料與主要執行個體進行同步處理。不過，建立新執行個體之後，該執行個體會延遲載入，進而導致複本延遲。這是正常反應。為了盡量縮短載入延遲的時間，請在建立僅供讀取複本時使用 IO1 類型的儲存，然後再視需要將其轉換回 GP2。

7.    在主要執行個體上分批執行交易。這樣可避免執行長時間交易，同時可將交易日誌檔縮到最小。除非複本延遲時間過長，否則請勿重新啟動複本執行個體，因為這樣做會使交易日誌檔的重新顯示延遲更久。

8.    修改主要執行個體或複本執行個體上的執行個體類別可能會造成暫時性的複本延遲。這是正常反應，因為必須處理主要執行個體中的日誌檔。

變更儲存體類型或儲存體大小對複本延遲有更長期的影響，影響時間直到儲存體最佳化完畢為止。無法得知 RDS 執行個體上已完成的儲存體最佳化百分比。

9.    如果僅供讀取複本達到儲存體完整狀態，則不會處理主要執行個體中的交易日誌檔，而且複本延遲時間會變長。

如果您懷疑儲存區中有 TempDB 或暫存資料表，請重新啟動複本執行個體以暫時釋出空間。

10.    如果複本延遲時間沒有縮短，請檢查複本執行個體上的使用者資料庫狀態。若要重新顯示日誌檔，資料庫狀態必須是「線上」。

請注意以下事項：

• 僅供讀取複本必須能夠存取新建立的資料庫，然後才能將這些資料庫納入延遲計算。
• 如果 RDS 無法判斷延遲時間 (例如在設定複本時或僅供讀取複本處於錯誤狀態時)，則 ReplicalAG 會傳回 -1。

---

相關資訊

在 Amazon RDS 中使用 Microsoft SQL Server 的僅供讀取複本