如何解決在 Aurora MySQL 相容版資料庫執行個體中使用讀取複本時出現的問題？

解決方法

提升與 Aurora MySQL 相容的讀取複本

如果寫入器執行個體需要重新啟動或維護，請執行手動容錯移轉，將讀取複本提升為寫入器執行個體。

若要執行手動容錯移轉，請完成以下步驟：

1. 開啟 Amazon RDS console (Amazon RDS 主控台)。
2. 在導覽窗格中，選擇 Databases (資料庫)。
3. 為您的 Aurora DB 叢集選取寫入器執行個體。
4. 選擇 Actions (動作)，然後選擇 Failover (容錯移轉)。

如果寫入器執行個體無法使用，則 Aurora MySQL 相容版會自動容錯移轉到讀取複本執行個體。寫入器執行個體可能會因為多種原因而變得無法使用，例如資源爭用或維護活動。

如果您有多個讀取器，請為叢集中的每個執行個體指定提升優先順序層級。當寫入器執行個體失敗時，Aurora MySQL 相容版會將優先順序最高的複本提升為新的寫入器。

您也可以將跨 AWS 區域 Aurora 複本提升為獨立的資料庫叢集。在您啟動提升程序後，系統會停止跨區域複寫。提升後的叢集將作為獨立的資料庫叢集執行，並管理讀取和寫入作業。

測量複寫延遲

由於資料庫叢集內的所有 Aruora 資料庫執行個體會共用一個通用資料磁碟區，因此會有最短的複寫延遲。但是，在某些情況下，您可能會遇到讀取器的延遲些微增加。

**注意：**跨區域複本使用二進位日誌複寫。跨區域複寫會受到所選區域之間的網路通訊速率和延遲的變更和套用所影響。使用 Aurora MySQL 資料庫的跨區域複本通常延遲不到 1 秒。

若要測量複寫延遲，請使用下列 Amazon CloudWatch 指標：

• AuroraReplicaLag 指標會測量同一區域內，寫入器節點和讀取器節點之間的複本延遲 (以毫秒為單位)。
• AuroraBinlogReplicaLag 指標會測量使用二進位日誌的 Aurora 資料庫叢集之間的複本延遲。

如需上述指標的詳細資訊，請參閱 Amazon Aurora 的執行個體級指標。

提高複寫效能

請執行下列動作：

• 若要避免讀取器執行個體上的任何工作負載超載，最佳做法是讓叢集內所有執行個體大小相同。當讀取執行個體的規格小於寫入執行個體時，變更的資料量過大，導致讀取執行個體無法及時同步。
  **注意：**如果寫入器執行個體上的工作負載繁重，則可能會有暫時的讀取複本延遲。當讀取執行個體的規格與寫入執行個體相符後，延遲時間會隨之減少。
• 若要避免在進行長時間執行的交易時出現複寫延遲，請以較小的批次執行交易並頻繁執行提交。

如需了解如何使用原生二進位日誌型 MySQL 複寫來對複本延遲問題進行疑難排解，請參閱 Amazon Aurora MySQL 複寫問題。

對高複寫延遲問題進行疑難排解

使用 AuroraReplicaLag CloudWatch 指標檢查高複寫延遲。高複寫延遲會導致讀取器執行個體重新啟動。若要解決此問題，請參閱為什麼我的 Amazon Aurora 讀取複本落後並重新啟動？

設定 GTID 型複寫

Aurora 不會使用原生二進位複寫來將資料複寫至讀取複本執行個體。您無法使用全域交易識別碼 (GTID) 複寫在相同叢集內執行個體之間的資料。但可以在特定情況下設定 GTID 型複寫。如需如何在相容的 Aurora MySQL 中使用基於 GTID 複寫的詳細資訊，請參閱 Amazon Aurora for MySQL 相容性現在支援全域交易識別碼 (GTID) 複寫。

對於 Aurora MySQL 相容版本 3.04 及更新版本，已啟用多執行緒二進位日誌複寫，並且 replica_parallel_workers 預設為 4。由於已啟用多執行緒二進位日誌複寫，您必須提高資料庫對於非預期中斷的韌性。最佳做法是在來源上啟用 GTID 複寫，並允許在複本上使用 GTID。

**注意：**您可以在 Amazon Relational Database Service (Amazon RDS) for MySQL 與 Aurora 叢集之間，以及在 Aurora 叢集之間，設定以 GTID 為基礎的複寫。來源必須是外部主伺服器。在開始複寫程序之前，請確認您已在來源上啟用二進位記錄。

如需 GTID 的詳細資訊，請參閱 MySQL 網站上的 GTID 格式和儲存。

相關資訊

跨 AWS 區域複寫 Amazon Aurora MySQL DB 資料庫叢集

使用 Amazon Aurora 進行複寫