Amazon Aurora數據庫群集無法正確自動平衡

Question

我創建了一個運行MySQL的Amazon Aurora數據庫集群，它有三個實例：支持集群的主實例和兩個用於平衡的只讀副本。 但是，群集似乎根本沒有平衡讀取。 我有一個副本管理700+選擇/秒最大化CPU為99.75％或更高，而另一個副本幾乎沒有任何CPU使用率為4％，每秒1選擇，如果這樣。 主要群集實例本身的CPU使用率為33％，因為正在讀取副本時正在同時寫入它。 復制品之間的滯后時間小於20毫秒。 我的應用程序正在查詢群集的只讀端點，但似乎沒有發生任何平衡。 有沒有人知道為什么會發生這種情況或為什么副本處於如此高的CPU使用率？ 無論如何，針對它運行的查詢都不復雜。

Answer 1

Aurora群集端點是DNS記錄，它們僅在解析期間執行DNS循環。 這意味着當您的客戶端應用程序打開與集群端點的連接時，您最終會將端點解析為不同的實例（基本上是不同的IP），通過在多個副本之間划分連接。 過去這一點，沒有負載平衡。 連接在實例之間進行條帶化，並且在每個連接上運行的查詢將轉到支持它的相應實例。

現在考慮當您在其后面有一個實例時已經為集群端點創建連接池的情況。 現在，如果添加更多實例，則不會對應用程序產生任何影響，除非您終止連接並重新建立連接。 您將再次執行DNS循環，這次您的一些連接將落在您配置的新實例上。

標注很少：

在Aurora中，您有2個群集端點。 一個（RW）端點始終指向當前寫入程序，一個（RO）在您的只讀副本之間執行DNS循環。

此外，發生故障轉移時，DNS傳播可能需要幾秒鍾，因此在發生故障轉移時偶然發生的錯誤非常自然。

希望這可以幫助。

Answer 2

我的猜測是你沒有連接到集群端點。

負載平衡 - 連接到群集端點允許Aurora對數據庫群集中的副本進行負載平衡。 這有助於擴展讀取工作負載，並可以提高性能，更公平地使用每個副本可用的資源。 如果發生故障轉移，如果您連接的副本被提升為主實例，則連接將被刪除。 然后，您可以重新連接到閱讀器端點，以便將讀取的查詢發送到群集中的其他副本。

適用於Amazon Aurora的新Reader端點 - 負載平衡和更高可用性

[編輯]

要在單個應用程序中進行負載平衡，您需要重新連接到端點。 如果對所有查詢使用相同的連接，則只有一個副本將響應。 但是，打開連接很昂貴，因此除非您的查詢需要一些時間才能運行，否則這可能無法提供太多好處。

Answer 3

我們已經實現了一個驅動程序來嘗試緩解這個問題，並獲得了一些明顯的收益： https ： //github.com/DiceTechnology/dice-fairlink

它會定期發現讀取副本以趕上群集更改和它們之間的循環連接。

盡管沒有測量任何CPU利用率，但我們觀察到的負載分布比集群讀取器端點的基於本機DNS的循環更好

Answer 4

Aurora基於DNS的負載均衡在連接級別（而不是單個查詢級別）工作。 您必須保持解析端點而不緩存DNS以在每個分辨率上獲得不同的實例IP。 如果您只解析端點一次，然后在池中保持連接，則該連接上的每個查詢都會轉到同一個實例。 如果緩存DNS，則每次解析端點時都會收到相同的實例IP。

除非您使用智能數據庫驅動程序，否則您將依賴DNS記錄更新和DNS傳播來實現跨Aurora副本的故障轉移，實例擴展和負載平衡。 目前，Aurora DNS區域使用5秒的短生存時間（TTL）。 確保您的網絡和客戶端配置不會進一步增加DNS緩存TTL。 請記住，DNS緩存可以發生在從網絡層，操作系統到應用程序容器的任何位置。 例如，Java虛擬機（JVM）因無限期緩存DNS而臭名昭着，除非另有配置。 以下是有關配置DNS緩存ttl的AWS 文檔和Aurora白皮書 。