RDS多可用性瓶頸寫入性能

Question

我們在sa-east-1區域使用RDS MySQL 5.6實例（db.m3.2xlarge），在寫入密集型操作期間，我們看到（在CloudWatch上）我們的寫入吞吐量和網絡傳輸吞吐量都限制在60MB / s 。

我們懷疑多可用區可能會對此行為負責，並將其關閉以用於測試目的。 我們做了相同的操作，現在注意到Write Througput不再受限制，網絡傳輸吞吐量實際上為零。 這強化了這種網絡流量在多可用區設置上的主實例和故障轉移實例之間的想法。

以下是Cloudwatch圖表，顯示沒有多可用區的操作，並且在啟用了多可用區的同一個操作之后：

我們嘗試將實例升級到具有最高網絡性能的實例，並且還配置了IOP，但沒有任何變化，當多可用區開啟時，我們的寫入總是限制在60MB / s。

我們的理解是，多可用區使用同步數據復制，但我們無法找到有關此復制發生的鏈路的帶寬限制的任何信息。 有誰知道它以及如何避免這種限制？ 或者我們應該忍受它嗎？

Answer 1

我不認為您看到復制服務本身的限制，但看起來您的復制帶寬與您的實例上的EBS卷共享相同的傳輸，因此它限制了您的實例本身可用的以太網帶寬（記住EBS是網絡附加存儲）。

m3.2xlarge上的網絡連接為1000 Mbit / s，相當於125 MiB / s。

將該數字除以2，您可以獲得~60 MB / s的速度來寫入本地實例的EBS卷，另一個~60 MB / s則可以寫入同步副本。

不幸的是，多邊復制復制的實現細節並不是AWS公開解釋的足夠詳細的內容，最終確實說這確實是解釋，但這些數字可疑地接近於正確預測的數據。

m3系列和m4系列實例具有相似的規格，但（顯然）也存在一些基本的設計差異，因此可以了解m4.2xlarge的相同行為是否正確。

Answer 2

我遇到了同樣的問題，在激活Multi AZ后，Write Latency顯着增加：

（實例類型為m4.4xlarge）

原因看起來是同步同步過程，每個寫入操作都必須等到兩個DB都對修改做出積極響應。

看起來沒有解決方案，這是一個預期的行為：

由於發生同步數據復制，與單可用區部署相比，使用多可用區部署的數據庫實例可能會增加寫入和提交延遲

- 來自AWS文檔

這是一個有趣的Redis線程：

• https://www.reddit.com/r/aws/comments/61ewvp/rds_multiaz_slow_insert/

我看到的唯一建議是搬到Aurora ：/

Answer 3

好吧，我從來沒有從任何地方得到任何實際的解釋，但經過大量的測試，似乎m3.2x.large實際上是“竊聽”。 我在博客中寫了詳細的解釋。