我可以如何解決在 Aurora 中使用讀取複本時的常見問題？

1 分的閱讀內容

我擁有 Amazon Aurora MySQL 相容版本 DB 執行個體，且在我使用讀取複本時遇到問題。我想要對這些問題進行疑難排解。

解決方法

升級 Aurora 讀取複本

若要將其他讀取複本執行個體升級為寫入器執行個體，請手動容錯移轉。

請完成下列步驟：

開啟 Amazon Relational Database Service (Amazon RDS) 主控台。
在導覽窗格中，選擇資料庫。
為您的 Aurora DB 叢集選取寫入器執行個體。
選擇 Actions（動作），然後選擇 Failover（容錯移轉）。

如果寫入器執行個體無法使用，Aurora 會自動容錯移轉至讀取複本執行個體。許多原因都會導致寫入器執行個體變得不可用，例如資源爭用和維護活動。

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

您也可將跨 AWS 區域 Aurora 複本升級為獨立 DB 叢集。在您啟動升級程序後，系統會停止跨區域複寫。新升級的叢集會作為獨立 DB 叢集運作，並同時管理讀取和寫入作業。

測量複寫延遲

由於 DB 叢集內的所有 Aruora DB 執行個體會共用一個通用資料磁碟區，因此會有最短的複寫延遲。然而，在某些情況下，您可能會發現讀取器上的延遲時間略為增加。

**注意：**跨區域複寫會採用邏輯複寫。跨區域複寫會受到所選區域之間的網路通訊速率和延遲的變更和套用所影響。使用 Aurora 資料庫的跨區域複本具有不到一秒的一般延遲。

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

AuroraReplicaLag 會測量同一區域內寫入器和讀取器節點間的複本延遲，單位為毫秒。
AuroraBinlogReplicaLag 會測量使用二進位日誌的 Aurora DB 叢集間的複本延遲。

提高複寫效能

若要改善複寫延遲，請執行下列動作：

如果讀取器執行個體小於寫入器執行個體，變更量則可能過大導致讀取器無法趕上。若要避免讀取器執行個體上的任何工作負載超載，最佳實務是讓叢集內所有執行個體大小相同。
**注意：**如果寫入器執行個體上的工作負載繁重，則可能會有暫時的讀取複本延遲。讀取器執行個體趕上寫入器執行個體後，此類延遲即會緩解。
如果長時間執行的交易進行中，則讀取器上可能會發生複本延遲。為避免複本延遲，請以更小的批次執行交易，並頻繁地執行提交。

若要瞭解如何使用原生 Binlog 型 MySQL 複寫疑難排解複本延遲，請參閱備份及還原 Aurora DB 叢集概觀。

疑難排解高複寫延遲

您可以在 AuroraReplicaLag CloudWatch 指標中查看高複寫延遲。高複寫延遲會導致讀取器執行個體重新啟動。若要防止因高複寫延遲而導致讀取器執行個體頻繁重新啟動，請參閱為什麼我的 Amazon Aurora 讀取複本落後並重新啟動？

設定基於 GTID 的複寫

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

**注意：**您可以在 Amazon RDS MySQL 和一或多個 Aurora 叢集間設定基於 GTID 的複寫。來源必須是外部主要來源。請務必先在來源上啟用 Binlog，再開始複寫程序。

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