使用Amazon RDS Proxy提升應用程序可用性

Amazon RDS Proxy的最大優(yōu)勢，在于顯著縮短數(shù)據(jù)庫故障轉移之后的應用程序恢復時間。RDS Proxy能夠同時支持MySQL與PostgreSQL引擎，但在本文中，我們將單純使用MySQL測試工作負載向大家展示RDS Proxy如何在故障轉移之后，將Amazon Aurora MySQL客戶端的恢復時間縮短達79%，并將Amazon RDS for MySQL的故障恢復時間縮短達32%。本文還將闡述RDS Proxy如何幫助客戶端擺脫讀取器終端節(jié)點-寫入器終端節(jié)點轉換問題，同時克服客戶端配置中的優(yōu)化不充分狀況。接下來，我們將討論在故障轉移期間閑置連接保留機制的支持下，RDS Proxy如何通過活動連接監(jiān)控與客戶端連接池機制帶來更出色的計劃內與計劃外故障轉移效果。最后，本文還將與大家分享一些關于客戶端配置的最佳實踐。

背景

RDS Proxy可以被放置在Amazon RDS for MySQL/PostgreSQL以及Aurora MySQL/PostgreSQL數(shù)據(jù)庫之前。它將幫助用戶管理應用程序對數(shù)據(jù)庫的訪問，同時提供連接池、多路復用以及良好的故障轉移功能。除了進一步擴展數(shù)據(jù)庫的連接限制之外，RDS Proxy還能夠管理應用程序的突發(fā)連接與請求。本文將著重介紹RDS Proxy在故障轉移層面的優(yōu)勢。

所謂故障轉移，就是當主數(shù)據(jù)庫實例無法正常訪問時，由另一實例接管并提升為新的主實例的過程。故障轉移會斷開客戶端連接。對于由管理操作（例如滾動升級）引發(fā)的故障轉移，我們將其稱為計劃內故障轉移；而由于真實故障引發(fā)的故障轉移，則屬于計劃外故障轉移。無論如何，我們都需要盡可能縮短停機時間以最大程度減少客戶端中斷造成的影響。

Amazon RDS提供多個高可用性選項，RDS Proxy則為各個選項提供故障轉移恢復支持。Amazon RDS多可用區(qū)選項能夠在主配置與輔助配置之間實現(xiàn)同步復制。Aurora則提供兩種高可用性選項，最多支持15個異步副本、以及多主模式。全部Aurora副本都處于只讀訪問模式，大家可以選定其中的任何一個副本節(jié)點并將其提升為集群的新主節(jié)點，而無需擔心引發(fā)數(shù)據(jù)丟失。Aurora多主模式則可提供多條活動寫入通道。

配合這些選項，在發(fā)生故障轉移時，客戶端需要首先檢測連接故障、發(fā)現(xiàn)新的主節(jié)點，并盡快與其重新連接。在RDS Proxy的協(xié)助下，應用程序能夠擺脫與故障轉移相關的復雜性因素，從而實現(xiàn)更快的恢復速度（僅需3秒）。Aurora中的故障轉移機制速度更快，其中DNS的傳播延遲就成了影響整體故障轉移時間的核心因素。RDS Proxy會主動監(jiān)控數(shù)據(jù)庫實例，并自動將客戶端接入正確的目標。此外，它還會在數(shù)據(jù)庫故障轉移期間繼續(xù)保留閑置的客戶端連接（而非將其丟棄）。所謂閑置連接，是指那些不包含重要請求的連接。

Aurora故障轉移

經過100次內部測試執(zhí)行之后，我們將Aurora集群直連模式與通過RDS Proxy建立的Aurora集群代理模式進行了故障轉移時間比較。

下表對結果進行了總結，單位為毫秒：

使用RDS Proxy時的平均故障轉移時長為3.1秒，使用MariaDB驅動程序進行數(shù)據(jù)庫直連的平均故障轉移時長則高達24秒。改進幅度高達87%。

對于關系數(shù)據(jù)庫來說，即使只是最基礎的基準測試，只需3秒的故障轉移速度也著實令人驚嘆。而這一切，都是Aurora努力創(chuàng)新的成果。但顯而易見的是，即使是以往表現(xiàn)最佳的MariaDB Aurora驅動程序（其中針對故障轉移進行了優(yōu)化）也不足以發(fā)揮Aurora的所有優(yōu)勢。只有配合RDS Proxy，我們才能真正讓Aurora MySQL的故障轉移變得迅如閃電，突破驅動程序本身對于數(shù)據(jù)庫恢復速度的限制。

DNS生存時間

大家可以采用多種不同方式調整客戶端驅動程序。例如，MariaDB ConnectorJ驅動程序就提供近100種配置選項。操作系統(tǒng)、JVM以及連接池框架中還包含更多配置選項。本文將只討論其中最重要的部分，首先自然是DNS客戶端緩存配置。

在客戶端使用DNS名稱接入數(shù)據(jù)庫時，首先需要通過查詢DNS服務器將該名稱解析為IP地址。客戶端隨后會將響應結果保存在緩存當中。根據(jù)協(xié)議，DNS響應結果中指定了生存時間（TTL），即控制客戶端將該記錄緩存多長時間。RDS中的TTL設置默認為4秒，但各類系統(tǒng)往往會在客戶端緩存中使用不同的設置，進一步延長TTL。操作系統(tǒng)與JVM運行時環(huán)境都存在這樣的緩存機制。JVM中的緩存設置因版本與操作系統(tǒng)而異，因此我們需要做出明確的設定。以下代碼所示，為建議設定值：

java.security.Security.setProperty("networkaddress.cache.ttl","1");

java.security.Security.setProperty("networkaddress.cache.negative.ttl","1");

這就縮短了JVM中的默認DNS緩存生存時間，使驅動程序能夠在故障轉移期間更快發(fā)現(xiàn)DNS名稱IP地址的變更。

配合客戶端優(yōu)化的故障轉移基準

在下一項基準測試中，我們將使用經過DNS TL設置優(yōu)化的客戶端（如前所述）以及本文稍后將談到的其他推薦客戶端設置。在下圖中，我們比較了使用最佳設置的MariaDB驅動程序與通過RDS Proxy接入Aurora MySQL時的故障轉移時間差異。

下表對測試結果做出匯總，單位為毫秒。

使用精心調優(yōu)的MariaDB客戶端，配合RDS Proxy時的平均故障轉移時間為2.9秒，而直連的平均故障轉移時間為13.8秒——RDS Proxy的改進幅度為79%。請注意，具體恢復時間還與實際工作負載密切相關。

Aurora客戶端配置

在之前的測試中，我們使用了針對Aurora做出增強優(yōu)化的MariaDB COnnectorJ。具體來講，指向該數(shù)據(jù)庫的直接連接使用以jdbc:mariadb:aurora://<cluster-endpoint>開頭的連接URL。如此一來，MariaDB COnnectorJ驅動程序就能夠使用Aurora中的專用系統(tǒng)標簽快速發(fā)現(xiàn)主數(shù)據(jù)庫實例。

通過RDS Proxy的連接則使用常規(guī)驅動程序，其中的URL為jdbc:mariadb://<proxy-endpoint>形式。盡管未使用任何特殊的客戶端配置，但RDS Proxy仍然取得了更好的故障轉移時間成績。更重要的是，其中的客戶端邏輯更加簡單，因此RDS Proxy將具有更好的普適性。

讀取器與寫入器角色轉換

一旦主實例出于某些原因而不再可用，Aurora會自動執(zhí)行故障轉移。在故障轉移期間，主實例會由寫入器角色轉換為讀取器角色；與此同時，Aurora集群中的某讀取器節(jié)點將被提升為主實例。如果直連集群端點，由于DNS記錄可能被緩存，因此客戶端仍可能繼續(xù)接入舊的主實例。這時，即使建立起連接，由于舊的主實例角色已經發(fā)生變化（轉換為只讀實例），客戶端將無法正常執(zhí)行寫入操作。RDS Proxy能夠消除此類錯誤，保證客戶端永遠只接入當前的主實例。

主動監(jiān)控與計劃外故障轉移

RDS Proxy并不依賴DNS傳播來執(zhí)行故障轉移，因此能夠改善整個轉移效果。RDS Proxy徹底消除了之前提到的Aurora集群客戶端讀取器-寫入器角色轉換的問題。它能夠主動監(jiān)控Aurora數(shù)據(jù)庫集群中的各個數(shù)據(jù)庫實例，并在故障轉移期間快速調整客戶端的操作方式。

到目前為止，本文所涉及的都只是計劃內/管理性故障轉移場景。對于Aurora，我們可以通過AWS管理控制臺、API或者AWS命令行界面（AWS CLI）根據(jù)需求調整實例大小，Amazon也可能根據(jù)用戶指定的維護計劃執(zhí)行集群調整，由這類操作帶來的都屬于計劃內故障轉移。在這類情況下，在數(shù)據(jù)庫進程未準備就緒時，數(shù)據(jù)庫主機將正常關閉連接并拒絕創(chuàng)建新的連接。這意味著客戶端或RDS Proxy能夠輕松檢測到問題，并稍后執(zhí)行重試。

但在計劃外故障轉移的場景下，主機會毫無征兆地突然失去可訪問性?，F(xiàn)有客戶端TCP連接仍然處于開啟狀態(tài)，而客戶端檢測到當前連接因收不到響應而造成死信。要應對這類情況，我們需要遵循以下最佳實踐，包括配置套接字超時、連接超時以及TCP繼續(xù)活動等。RDS Proxy也可以協(xié)助客戶端順利應對這類計劃外故障轉移。

RDS Proxy會監(jiān)控每個數(shù)據(jù)庫實例，并在幾秒鐘之內檢測到故障。一旦發(fā)現(xiàn)故障，RDS Proxy將停止將新查詢定向至存在故障的數(shù)據(jù)庫實例。在故障轉移期間，RDS Proxy還會保留各閑置客戶端連接，意味著存在非活動連接的客戶端連接池也能夠更輕松地處理故障轉移，而無需重新創(chuàng)建每一條連接。如此一來，客戶端將節(jié)約下重建閑置TLS連接所帶來的開銷。另外，RDS Proxy還能夠主動終止故障數(shù)據(jù)庫實例中那些未執(zhí)行完畢的事務，幫助客戶端快速重試（而不必等待超時）。

RDS Proxy始終接受新連接，并會延后轉發(fā)查詢，直到新的主實例恢復可用為止。如果沒有RDS Proxy，一旦發(fā)生故障轉移，客戶端只會檢測到主數(shù)據(jù)庫實例不可用，并可能立即嘗試重新連接。由于主數(shù)據(jù)庫仍在恢復當中，這些重連嘗試往往不會成功。而一旦重新連接次數(shù)過多，主實例的恢復很可能因此而再次崩潰。結果就是，客戶端的重試邏輯反而加重了故障的嚴重程度。但在RDS Proxy的加持下，我們根本不需要建立這種復雜的重試邏輯。

Amazon RDS多可用區(qū)模式

Amazon RDS的多可用區(qū)模式，是一項有助于緩解計劃外故障轉移影響的重要功能。使用RDS MySQL中的多可用區(qū)配置時，主數(shù)據(jù)庫實例將位于某一可用區(qū)內，而同步備用實例則位于其他可用區(qū)。此時，客戶端應用程序將使用某項主機名稱指向數(shù)據(jù)庫的主實例。一旦發(fā)生故障，RDS服務將切換主實例與輔助實例之間的角色。此外，RDS服務還將變更數(shù)據(jù)庫主機名稱的基礎IP地址，確?？蛻舳藨贸绦驘o需變更自身連接設置即可在故障轉移期間直接接入新的主數(shù)據(jù)庫實例。

使用Amazon RDS多可用區(qū)模式，原始主實例在故障轉移期間不再需要關閉其TCP連接。故障轉移開始后，客戶端將不再從數(shù)據(jù)庫處獲取更多TCP流量，而是由客戶端自主判斷是否超時。這種精心設計的原始主數(shù)據(jù)庫實例硬防護機制，意味著客戶端能夠隨時從容應對計劃內與計劃外故障轉移。這樣做的最大好處在于，只需要通過Amazon RDS API或CLI進行管理性故障轉移，即可輕松對現(xiàn)有系統(tǒng)的計劃內與計劃外故障轉移效果做出測試。但需要注意的是，MariaDB驅動程序以及多數(shù)操作系統(tǒng)中的默認設置并不能夠很好地配合多可用區(qū)模式。在默認情況下，MariaDB驅動程序永遠不會將響應等待判定為超時，而某些操作系統(tǒng)的TCP活動保持周期可能超過2個小時。但好消息是，RDS Proxy將徹底消除這些設置，現(xiàn)在主機名稱的基礎DNS配置（在本示例為中RDS Proxy）將永遠不會變更。

RDS多可用區(qū)故障轉移恢復基準

以下結果，為使用MariaDB驅動程序直連數(shù)據(jù)庫與通過RDS Proxy連接時，對50次故障轉移的測試結果。表內各項數(shù)值的單位為毫秒。

總之，將RDS Proxy與Amazon RDS多可用區(qū)數(shù)據(jù)庫配合使用，平均故障轉移周期約為25秒；而數(shù)據(jù)庫直連模式的停機時間則在37秒到40秒之間。

而且與Amazon RDS多可用區(qū)的25秒恢復時間相比，Aurora在db.r5.large實例上的恢復時間甚至可以做到3秒以內。這主要是因為Aurora當中包含多項創(chuàng)新功能，可在故障轉移之后加快數(shù)據(jù)庫的恢復時間。

總結

本文向大家介紹了RDS Proxy的以下幾項核心優(yōu)勢：

·在測試工作負載中，將Aurora MySQL的故障轉移時間縮短達79%。

·在測試工作負載中，將RDS MySQL多可用區(qū)的故障轉移時間縮短達32%。

·無需特殊的客戶端邏輯，能夠與多種不同客戶端驅動程序良好對接。

·將客戶端與Aurora集群中的讀取方-寫入方角色轉換隔離開來。

·主動監(jiān)控各數(shù)據(jù)庫，包括計劃外故障轉移跡象。

·在故障轉移期間不丟棄閑置連接，從而減少對客戶端連接池的影響。

·始終接受連接，使客戶端免受連接超時的影響。

RDS Proxy也非常易于上手。大家可以將任何MySQL或者PostgreSQL客戶端驅動程序與RDS Proxy端點相對接，并立即享受由其帶來的便利。歡迎大家馬上開始體驗RDS Proxy！