我該如何對導致 Aurora 讀取複本發生延遲並重新啟動的問題進行疑難排解？

解決方法

**注意：**以下解決方法適用於單一 AWS 區域中的 Aurora 叢集，以及全球資料庫主要叢集，不適用於全球資料庫次要叢集。

測量 AuroraReplicaLag

Aurora 複本會連線至與寫入器執行個體相同的儲存磁碟區。Aurora 會將變更同步寫入共用儲存磁碟區，但會以非同步方式將變更複寫至讀取器執行個體。為了確保讀取一致性，Aurora 會使與變更相關、快取於記憶體中的資料失效。資料快取包含緩衝區集區或頁面快取。

在某些情況下，將變更傳播至讀取器執行個體時可能會發生延遲。此延遲會顯示為 Amazon CloudWatch 中 AuroraReplicaLag 指標的增加，這可能導致重新啟動，且您可能會收到以下錯誤訊息：

「Read Replica has fallen behind the master too much.Restarting」。

對於 Amazon Aurora MySQL 相容版，請在 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 資料表上執行以下查詢，以測量 AuroraReplicaLag：

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

輸出範例：

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

對於 Amazon Aurora PostgreSQL 相容版，請執行以下查詢以取得 aurora_replica_status() 函式，並篩選結果：

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

輸出範例：

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

確保叢集中所有執行個體具有相同的規格

如果讀取器執行個體的資料庫執行個體類別組態低於寫入器資料庫執行個體，則變更數量可能過大。導致讀取器執行個體無法在快取中進行失效處理。為避免此問題，最佳實務是讓 Aurora 叢集中所有資料庫執行個體維持相同的規格。

使用指標和增強型監控功能監控工作階段

當您同時執行多個工作階段時，讀取器執行個體可能會發生延遲。由於可用資源不足，Aurora 複本可能會緩慢地套用來自寫入器的必要變更。若要檢查延遲，請查看 CPUUtilization、DBConnections 以及 NetworkReceiveThroughput 指標。您也可以開啟精細程度為 1 或 5 秒的增強型監控，以了解讀取器上的資源使用情況。或者，啟用 Performance Insights 並使用 Database Insights 來視覺化讀取器的工作負載。對於 Aurora PostgreSQL 相容版，您可以使用 ReadIOPS 指標。

重要：Performance Insights 將於 2026 年 6 月 30 日終止服務。您可以在 2026 年 6 月 30 日之前升級至 Database Insights 的進階模式。如果不升級，則使用 Performance Insights 的資料庫叢集將預設為 Database Insights 的標準模式。只有 Database Insights 的進階模式才支援執行計畫和隨需分析。如果您的叢集預設為標準模式，那麼您可能無法在主控台上使用這些功能。若要開啟進階模式，請參閱 在 Amazon RDS 中開啟 Database Insights 進階模式與在 Amazon Aurora 中開啟 Database Insights 進階模式。

使用 CloudWatch 視覺化寫入活動

在原本就以寫入為主的生產環境叢集中，寫入活動的突然激增可能會使寫入器資料庫執行個體超載。此超載可能導致讀取器執行個體延遲。請使用 CloudWatch 查看顯示突然激增流量的 DMLThroughput、DDLThroughput 以及 Queries 指標。對於 Aurora PostgreSQL 相容版，請查看 WriteThroughput 指標。

針對 Aurora MySQL 相容版的長時間執行交易問題進行疑難排解

MySQL InnoDB 引擎預設使用多版本並行控制 (MVCC)。因此，您必須追蹤在交易期間對資料列所發生的所有變更。當長時間執行的交易完成後，清除執行緒活動會出現尖峰。此突發的清除作業可能因長時間交易所建立的大量待處理項目，而導致 Aurora 複本延遲。

對於 Aurora MySQL 相容版，請檢查 CloudWatch 中的 RollbackSegmentHistoryListLength 指標以查看清除尖峰。您可以執行 SHOW ENGINE INNODB STATUS 命令來查看清除情況。或者，執行以下查詢：

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

輸出範例：

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

設定 CloudWatch 警示以監控 RollbackSegmentHistoryListLength，確保其不會達到過高的數值。在關聯式資料庫中，最佳實務是避免長時間執行的交易。

避免短暫的網路中斷

雖然相當罕見，但寫入器與讀取器執行個體之間，或執行個體與 Aurora 儲存層之間，仍可能發生暫時性的網路通訊失敗。由於短暫的網路中斷，讀取器執行個體可能會發生延遲或重新啟動。當大量變更使執行個體的網路頻寬超載時，Aurora 複本也可能發生延遲。為避免此問題，最佳實務是調整資料庫執行個體的大小，使其能夠處理該數量的變更。

相關資訊

將 Aurora 複本新增至資料庫叢集

Amazon Aurora MySQL 相容版的複寫

Amazon Aurora 叢集中的監控指標

Amazon Aurora 的執行個體層級指標