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

1 分的閱讀內容
0

我擁有 Amazon Aurora MySQL DB 執行個體,且在使用讀取複本時遇到問題。如何疑難排解在透過 Amazon Aurora 使用讀取複本時的常見問題?

簡短說明

Amazon Aurora MySQL 支援的讀取複本須與同一 AWS 區域內的寫入器 DB 執行個體共用通用基礎磁碟區。若您變更寫入器 DB 執行個體,相應更新會在 DB 叢集內的讀取複本中顯示。您也可建立跨區域 MySQL 讀取複本。這些操作都會透過 MySQL 基於 Binlog 的複寫引擎實作。

使用 Aurora 複本是擴展讀取作業的最佳做法。若要執行此操作,您需要減少寫入器上的讀取工作負載。然後提高可用性以處理速度緩慢或妨礙擴展的事件。

解決方法

如何升級 Aurora 讀取複本?

手動容錯移轉 - 按照以下步驟操作以執行手動容錯移轉,將其他讀取複本執行個體升級為寫入器執行個體:

  1. 登入 Amazon Relational Database Service (Amazon RDS) 主控台
  2. 從導覽窗格中選擇 Databases(資料庫)。
  3. 為您的 Aurora DN 叢集選擇寫入器執行個體。
  4. 選擇 Actions(動作),然後選擇 Failover(容錯移轉)。

自動容錯移轉 - 如果寫入器執行個體無法使用,Aurora 會自動容錯移轉至讀取複本執行個體。許多原因都可能導致此情況發生,包括資源爭用和維護活動。如果您有多個讀取器,可以為叢集內每個執行個體提供升級優先順序層級。當寫入器執行個體失敗時,Aurora 會將優先順序最高的複本升級為新的寫入器。

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

如何測量複寫延遲?

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

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

您可以使用下列 Amazon CloudWatch 指標來測量複寫延遲:

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

如何提高複寫效能?

請依照以下建議來改善複本延遲:

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

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

能否使用全域交易識別符 (GTID)?

全域交易識別符是在提交交易時,與該筆交易相關連的唯一字串。GTID 在所有伺服器上都不會重複,且變更會根據 GTID 值套用至目標。如需詳細資訊,請參閱 MySQL 文件的 GTID 概念

Aurora 不會使用原生 Binlog 複寫來將資料複寫至讀取複本執行個體。您無法使用 GTID 在同一叢集內的執行個體間複寫資料。但可以在特定情況下設定基於 GTID 的複寫。若要深入瞭解如何在 Aurora MySQL 內使用基於 GTID 的複寫,請參閱 AWS 部落格中有關 GTID 的內容。

**注意:**您可以在 Amazon RDS MySQL 和一或多個 Aurora 叢集間設定基於 GTID 的複寫 (若為多個叢集,須由外部主機擔任來源)。請務必先在來源上啟用 Binlog,再開始複寫程序。


相關資訊

使用 Amazon Aurora 進行複寫

什麼是 Amazon Aurora?

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