為什麼我的 Amazon Aurora 讀取複本落後並重新啟動?

2 分的閱讀內容
0

我正在執行生產環境的 Amazon Aurora 資料庫叢集。我的讀取器執行個體已重新啟動,並顯示錯誤訊息 "Read Replica has fallen behind the master too much.Restarting MySQL"(讀取複本比主節點落後太多。正在重新啟動 MySQL。)或 "Read Replica has fallen behind the master too much.Restarting postgres."(讀取複本比主節點落後太多,正在重新啟動。)

簡短說明

AuroraReplicaLag 是將寫入器 Aurora 資料庫執行個體的變更複寫到 Aurora 資料庫叢集中的讀取器執行個體時的延遲測量 (以毫秒為單位)。Aurora 複本會連線至與寫入器執行個體相同的儲存磁碟區。若要測量寫入器執行個體與讀取器執行個體之間的延遲,請使用 Amazon CloudWatch 中的 AuroraReplicaLag 指標。

對於 Aurora 資料庫叢集,AuroraReplicaLag 指標會指出 Aurora 複本的資料快取相較於寫入器資料庫執行個體的延遲。資料快取包括緩衝集區或頁面快取。這些變更會同步寫入共用儲存磁碟區。但是,變更卻以非同步方式複寫到讀取器執行個體,在此情況下,記憶體中任何與變更相關的快取資料都會失效,以達到讀取一致性。在某些情況下,在讀取器執行個體之間傳播變更時可能會有延遲。此延遲表現為 CloudWatch 中的 AuroraReplicaLag 指標增加,最終可能導致重新啟動。

您可以測量有關 AuroraReplicaLag 近乎即時的中繼資料:

對於與 Amazon Aurora MySQL 相容的版本,請從 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 表格中進行選取:

mysql> 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() 函數並篩選結果:

postgres=> 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)

**注意事項:**本文提供的解決方案適用於 Amazon Aurora 單一區域和全域資料庫主要叢集,而非全域資料庫次要叢集。

解決方案

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

如果讀取器執行個體的資料庫執行個體類別組態比寫入器資料庫執行個體還弱,則變更量可能過大。在這種情況下,讀取器執行個體無法在快取中失效,然後擷取並更新。因此,最佳實務是讓 Aurora 叢集中的所有資料庫執行個體都具有相同的規格。

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

當多個工作階段同時執行時,讀取器執行個體可能會發生延遲情況。由於缺少可用資源,因此 Aurora 複本在套用來自寫入器的必要變更時可能會很慢。您可以在 CPUUtilizationDBConnectionsNetworkReceiveThroughput 等指標中觀察到此延遲情況。您也可以使用 **1 或 5 ** 秒的精細程度開啟增強型監控,以了解讀取器的資源用量。還可以使用效能深入分析將其工作負載視覺化。此外,針對僅與 Aurora PostgreSQL 相容的執行個體,請使用 ReadIOPS 指標。

使用 CloudWatch 將寫入活動視覺化

在已有密集寫入的生產環境叢集中若發生寫入活動突然激增,可能會導致寫入器資料庫執行個體超載。激增帶來的壓力增加可能會導致一或多個讀取器執行個體落後。您可以在 CloudWatch 中觀察到這一點,其表現為 DMLThroughput, DDLThroughputQueries 指標的突然激增。

對於 Aurora PostgreSQL,您可以在 WriteThroughput 指標中觀察到這一點。

調查越來越高的歷史記錄清單長度 (HLL) (與 Aurora MySQL 相容)

MySQL InnoDB 引擎預設合併了多版本並行控制 (MVCC)。這表示您必須追蹤整個交易過程中所有受影響資料列上發生的所有變更。長時間執行的交易完成後,清除執行緒活動便開始突增。由於長時間執行的交易所建立的待辦項目數量龐大,突然清除可能會導致 Aurora 複本落後。

在 1.19.2、2.06 及更高版本上,Aurora MySQL 包含 RollbackSegmentHistoryListLength 指標。您可以在 CloudWatch 中使用此指標來觀察此清除狀況。還可以在 SHOW ENGINE INNODB STATUS 的輸出中查看,或透過以下方式查詢資訊結構描述來查看:

mysql> 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 警示以監控此指標,使其不會達到過高的數字。在關聯式資料庫中,最佳實務是避免長時間執行的交易。

防止短暫的網路中斷

雖然很罕見,但在寫入器與讀取器執行個體之間或執行個體與 Aurora 儲存層之間可能會發生暫時性的網路通訊失敗。由於網路短暫中斷,讀取器執行個體可能會落後或重新啟動。由於大量變更而導致執行個體的網路頻寬飽和,Aurora 複本也可能會落後。最佳實務是考慮資料庫執行個體的大小及其網路功能,以避免此問題。


相關資訊

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

使用 Amazon Aurora MySQL 進行單一主節點複寫

監控 Amazon Aurora 叢集中的指標

AWS 官方
AWS 官方已更新 1 年前