AWS Aurora 數(shù)據(jù)庫 Failover 處理方案
Aurora簡述
Amazon Aurora 是亞馬遜自研的云原生數(shù)據(jù)庫，除兼容性、性能、擴(kuò)展性外，它在設(shè)計(jì)之初，就以極致的可用性作為目標(biāo)，盡可能減少故障對應(yīng)用程序的影響。
Amazon Aurora 在故障恢復(fù)方面的設(shè)計(jì)理念主要包括：
- 1. 能在較大范圍故障時(shí)仍然提供服務(wù)：跨3個(gè)可用區(qū)的6備份存儲(chǔ)使它在一個(gè)可用區(qū)和另一個(gè)額外備份發(fā)生故障時(shí)仍能提供服務(wù)；跨區(qū)域的全球數(shù)據(jù)庫能在主區(qū)域發(fā)生故障時(shí)快速切換到從區(qū)域；
- 2. 加快故障恢復(fù)的速度：將數(shù)據(jù)拆分成10 GB 粒度存儲(chǔ)單元使單個(gè)存儲(chǔ)單元能在秒級別恢復(fù)；通過分布式存儲(chǔ)進(jìn)行并行恢復(fù)等；快速找到健康計(jì)算節(jié)點(diǎn)先進(jìn)行節(jié)點(diǎn)替換來使整個(gè)集群盡快提供服務(wù)。
Amazon Aurora 的架構(gòu)示意圖如上所示，僅有Primary RW（Read/Write） DB一個(gè)主節(jié)點(diǎn)用于處理寫請求，而其余的則為從節(jié)點(diǎn)Secondary RO（Read-Only） DB用于處理讀請求，在其論文中指出Secondary RO DB可以多達(dá)15個(gè)。（ Aurora論文翻譯版本 ）
Aurora有多主架構(gòu)嗎？如果是多主架構(gòu)會(huì)怎樣？
它們以端點(diǎn) cluster endpoint 的形式對外提供服務(wù)，用戶可以通過讀寫端點(diǎn)來訪問 Aurora 寫節(jié)點(diǎn)；通過只讀端點(diǎn)訪問 Aurora 讀節(jié)點(diǎn)。
這里的只讀端點(diǎn)只有一個(gè)，我們在應(yīng)用程序中的配置也只有一個(gè)，但并不表示我們只有一個(gè)只讀實(shí)例。
只讀端點(diǎn)下面可以掛載多個(gè)實(shí)例，通過 Route53（高度可用和可擴(kuò)展的云托管域名系統(tǒng) (DNS) 服務(wù)） 進(jìn)行負(fù)載輪訓(xùn)到不同的只讀節(jié)點(diǎn)實(shí)例。
Failover介紹
在 Amazon Aurora 中，F(xiàn)ailover 是指在主節(jié)點(diǎn)不可用時(shí)，自動(dòng)或手動(dòng)的將一個(gè)從節(jié)點(diǎn)提升為新的主節(jié)點(diǎn)的過程。
Failover 通常發(fā)生在以下情況：
主節(jié)點(diǎn)故障：如果主節(jié)點(diǎn)發(fā)生故障或停止服務(wù)，Amazon Aurora 將自動(dòng)將一個(gè)從節(jié)點(diǎn)提升為新的主節(jié)點(diǎn)，以確保數(shù)據(jù)庫的高可用性和容錯(cuò)性。
可用區(qū)故障：如果主節(jié)點(diǎn)所在的可用區(qū)發(fā)生故障，Amazon Aurora 將自動(dòng)將一個(gè)在其他可用區(qū)中的從節(jié)點(diǎn)提升為新的主節(jié)點(diǎn)。
手動(dòng)干預(yù)：如果需要執(zhí)行主節(jié)點(diǎn)的計(jì)劃維護(hù)或升級操作，可以手動(dòng)將一個(gè)從節(jié)點(diǎn)提升為新的主節(jié)點(diǎn)，以確保數(shù)據(jù)庫的可用性和穩(wěn)定性。
當(dāng)寫節(jié)點(diǎn)發(fā)生故障時(shí)，Aurora 會(huì)進(jìn)行如下的 Failover 過程：
1. 根據(jù)不同節(jié)點(diǎn) failover 優(yōu)先級和復(fù)制延遲來選擇一個(gè)讀節(jié)點(diǎn)，將其提升成新的寫節(jié)點(diǎn)。因?yàn)樵摴?jié)點(diǎn)角色發(fā)生切換，需要重啟該節(jié)點(diǎn)。
2. 嘗試恢復(fù)原來的寫節(jié)點(diǎn)并讓它成為新的讀節(jié)點(diǎn)。這里也會(huì)涉及到節(jié)點(diǎn)重啟。
3. 待新的寫節(jié)點(diǎn)重啟成功以后，定位讀寫端點(diǎn)指向新的寫節(jié)點(diǎn)。這里涉及到域名的更新，依賴于 Route53 的實(shí)現(xiàn)。
4. 待新的讀節(jié)點(diǎn)重啟成功以后，定位只讀端點(diǎn)指向新的讀節(jié)點(diǎn)。這里同樣涉及到域名更新，依賴于 Route53 的實(shí)現(xiàn)。
AWS在控制臺(tái)提供了手動(dòng)觸發(fā)failover的操作，我們可以通過觀測 Event 事件來查看 failover 過程中 Aurora 的讀寫節(jié)點(diǎn)究竟發(fā)生了哪些操作。
以一寫一讀的集群為例，在控制臺(tái)點(diǎn)擊 failover，可以觀測并整理出如下事件。
并繪制出事件時(shí)間圖
整個(gè)集群 failover 過程在29秒完成，其中，新的寫節(jié)點(diǎn)重啟成功用了7秒，新的寫節(jié)點(diǎn)在7秒以后就可以接受請求。
由于用戶訪問 Aurora 是利用域名的方式（Aurora 的讀寫域名和只讀域名），新寫節(jié)點(diǎn)啟動(dòng)后需要更新域名，而域名更新需要一定的時(shí)間，所以應(yīng)用程序在數(shù)據(jù)庫實(shí)例可用到 DNS 更新完成這個(gè)時(shí)間段內(nèi)通過域名的方式連接 Aurora 集群時(shí)會(huì)發(fā)生連接錯(cuò)亂的現(xiàn)象。
在DNS發(fā)生切換前，使用寫域名會(huì)連接到新讀庫上、使用讀域名會(huì)連接到新寫庫上。而這種情況會(huì)對應(yīng)用程序產(chǎn)生較大影響~~~
Failover對應(yīng)用程序的影響
我們分別使用Maria和AWS驅(qū)動(dòng)做了測試。
這里我們使用當(dāng)前自身中間件版本的 ORM （基于 Mybatis 的封裝）和 Maria驅(qū)動(dòng)，分析每個(gè)階段對程序的讀寫影響。
階段一
這個(gè)階段還未開始觸發(fā)failover，讀寫一切正常。
階段二
這個(gè)階段讀庫開始并正在重啟中，寫庫正常，對于寫庫的操作一切正常。
讀庫連接池狀態(tài): RO - Pool Status: Active: 0, Idle: 0, Total: 0, Waiting: 1
寫庫連接池狀態(tài): WR - Pool Status: Active: 1, Idle: 1, Total: 2, Waiting: 0
DEBUG級別日志：Connection refused (Connection refused)- 補(bǔ)充讀庫連接
對于讀庫的操作則會(huì)發(fā)生慢接口（queryTime > 業(yè)務(wù)sql執(zhí)行時(shí)間 + 階段二 + 階段三）。但這并不會(huì)意味著一定會(huì)產(chǎn)生ERROR異常，具體要看連接參數(shù)connection-timeout設(shè)置和restart的過程時(shí)長。
connection-timeout > restart
會(huì)有長查詢，但不會(huì)有ERROR級別異常。因?yàn)闀?huì)在restart成功后正常建立TCP連接。
在這個(gè)過程中，Hikari連接池會(huì)做很多事情。
首先，這個(gè)階段連接池內(nèi)的連接都是一個(gè)time_wait狀態(tài)的，獲取連接時(shí)，這個(gè)連接如果空閑超出500ms，會(huì)在連接存活檢測失效，如果空閑在500ms內(nèi)，會(huì)在執(zhí)行請求時(shí)立即得到連接關(guān)閉的狀態(tài)。
不管哪種此時(shí)連接池都會(huì)把它關(guān)閉并從維護(hù)的池中清理，直到把維護(hù)的連接都嘗試并清理個(gè)遍，然后嘗試創(chuàng)建新的連接進(jìn)行補(bǔ)充。
如果此時(shí)我們開啟DEBUG日志的話會(huì)看到大量Connection refused (Connection refused)debug級別日志，只要restart時(shí)間在connection-timeout的范圍內(nèi)，也就無所謂了，大不了就查詢時(shí)間長一些。
connection-timeout < restart
這時(shí)是會(huì)真的報(bào)ERROR級別的錯(cuò)誤了
Cause: java.sql.SQLTransientConnectionException: single:RO - Connection is not available, request timed out after 30005ms.
階段三
主從數(shù)據(jù)庫全部不可用
寫庫也會(huì)進(jìn)入讀庫的上個(gè)階段
階段四
讀庫連接池逐漸補(bǔ)充、讀請求正常
[single:RO connection adder] DEBUG com.zaxxer.hikari.pool.HikariPool - single:RO - Added connection org.mariadb.jdbc.MariaDbConnection@515740ab
讀庫連接池狀態(tài): RO - Pool Status: Active: 1, Idle: 1, Total: 2, Waiting: 0
注意： 此時(shí)DNS并未發(fā)生切換，補(bǔ)充進(jìn)來的讀庫連接實(shí)際上是連接到老的讀庫上（新的寫庫）。
階段五
寫庫連接池逐漸補(bǔ)充、寫請求發(fā)生 --read-only異常?。。?/p>
[single:WR connection adder] DEBUG com.zaxxer.hikari.pool.HikariPool - single:WR - Added connection org.mariadb.jdbc.MariaDbConnection@2ca547c0
寫庫連接池狀態(tài): WR - Pool Status: Active: 1, Idle: 1, Total: 1, Waiting: 0
注意： 此時(shí)DNS并未發(fā)生切換，補(bǔ)充進(jìn)來的寫庫連接實(shí)際上是連接到老的寫庫上（新的讀庫）。
階段六
連接池狀態(tài)
RO - Pool Status: Active: 0, Idle: 2, Total: 2, Waiting: 0
WR - Pool Status: Active: 1, Idle: 2, Total: 3, Waiting: 0
應(yīng)用異常日志
15:36:55.030 [http-nio-8080-exec-7] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.jdbc.UncategorizedSQLException:
### Error updating database. Cause: java.sql.SQLException: (cnotallow=5) The MySQL server is running with the --read-only option so it cannot execute this statement
### The error may exist in file [/sample-single/target/classes/mapper/StatusMapper.xml]
### The error may involve sample.orm.single.mapper.StatusMapper.longUpdate-Inline
### The error occurred while setting parameters階段七
- 1. 讀請求正常
- 2. 寫請求持續(xù) read-only，直到連接生命周期結(jié)束（默認(rèn)30分鐘）
。。。
很顯然、30分鐘的寫業(yè)務(wù)不可用是不可接受的……
如何應(yīng)對數(shù)據(jù)庫的Failover
通常情況下，Aurora 的 failover 通常能在30~60秒左右內(nèi)完成，對應(yīng)用程序產(chǎn)生較低影響。
那么，是否有可能進(jìn)一步加快 Aurora failover 的速度呢？實(shí)現(xiàn)部分會(huì)重點(diǎn)介紹如何在 Aurora 進(jìn)行故障恢復(fù)的時(shí)候避免或者減少 DNS 的影響，從而加快故障切換速度。
控制客戶端 DNS TTL 的時(shí)間
檢查客戶端是否緩存了DNS及設(shè)置時(shí)間，如果設(shè)置較久的話，可以考慮將客戶端的 DNS 的 TTL 調(diào)小，但這并不能消除DNS切換帶來的影響。
數(shù)據(jù)庫實(shí)例的底層 IP 地址在故障轉(zhuǎn)移完成后可能會(huì)發(fā)生變化，也就是說如果我在故障轉(zhuǎn)移過程中建立連接還是會(huì)有出錯(cuò)的可能性。
使用 RDS Proxy
RDS Proxy 是基于 Aurora/RDS 之上提供的一個(gè)代理層，它有三個(gè)特性：
1. 連接池能夠?qū)崿F(xiàn)連接的多路復(fù)用，如果應(yīng)用對數(shù)據(jù)庫的并發(fā)請求比較多，直接打到 Aurora 數(shù)據(jù)庫上會(huì)耗費(fèi)很多資源?？梢允褂?RDS Proxy 來實(shí)現(xiàn)連接復(fù)用，支持更多的并發(fā)應(yīng)用，并減少新建連接的需要。
2. 增強(qiáng)的安全性，如果不希望直接把底層數(shù)據(jù)庫的密碼直接暴露，可以使用 RDS Proxy，通過使 RDS Proxy 訪問 Secrets Manager 里的密碼來增強(qiáng)安全性。
3. 快速的故障恢復(fù)時(shí)間，RDS Proxy 避開了 Aurora 發(fā)生故障切換時(shí)節(jié)點(diǎn)切換帶來的域名 DNS 記錄更新的問題，用戶通過連接 RDS Proxy 可以避免域名更新的時(shí)間消耗。
AWS 的另一個(gè)產(chǎn)品，據(jù)說會(huì)有SQL上的性能損耗，未使用、未調(diào)研、未測試。
AWS智能驅(qū)動(dòng)
智能驅(qū)動(dòng)在連接到 Aurora 集群時(shí)，會(huì)拿到整個(gè)集群的拓?fù)浜透鱾€(gè)節(jié)點(diǎn)的角色信息（是寫節(jié)點(diǎn)還是讀節(jié)點(diǎn)）維持在緩存中。
有了這個(gè)拓?fù)?，在?jié)點(diǎn)發(fā)生變化時(shí)，就可以快速拿到變化的節(jié)點(diǎn)的角色信息，而無需再依賴的 DNS 的解析。
AWS 官方圖
上圖是AWS智能驅(qū)動(dòng)自身的邏輯示意，應(yīng)用程序連接到它時(shí)，會(huì)維護(hù)一個(gè)邏輯的連接和物理的連接。
比如現(xiàn)在的寫節(jié)點(diǎn)是 C，但同時(shí)它的拓?fù)渚彺嬷袝?huì)存放著節(jié)點(diǎn) A 和 B 的信息，這樣如果節(jié)點(diǎn) C 發(fā)生了故障，能夠及時(shí)檢測并將物理連接切換到 A 或 B 節(jié)點(diǎn)（取決于 Aurora 決定 failover 到哪個(gè)節(jié)點(diǎn)）而邏輯連接是保持不變的。
智能驅(qū)動(dòng)與 MySQL 的普通驅(qū)動(dòng)使用方法是一樣的，您只需要更換驅(qū)動(dòng)，并將連接字符串更換為如下格式即可。
注意這里的 url 的字符串前面是 jdbc:mysql:aws。缺省情況下，故障切換的能力是開啟的，也可以通過參數(shù)調(diào)整的方式進(jìn)行關(guān)閉。
jdbc:mysql:aws://集群名稱.集群id.us-east-2.rds.amazonaws.com:3306/數(shù)據(jù)庫名?useSSL=false&characterEncoding=utf-8
在對AWS智能驅(qū)動(dòng)實(shí)驗(yàn)中，failover這塊表現(xiàn)甚好，查看其failover代碼實(shí)現(xiàn)，發(fā)現(xiàn)其為每個(gè)連接綁定了一套插件執(zhí)行鏈，其中就有failover插件。
AWS 官方圖
插件鏈的執(zhí)行必然會(huì)對SQL帶來點(diǎn)性能上的損失，為了能夠正常failover，這點(diǎn)損失也能接受。
查看其版本變化和ISSUE、嗯…… 很活躍。
中間件的處理方式
AWS是自己實(shí)現(xiàn)了JDBC的Connection，為每一個(gè)連接綁定了插件機(jī)制，在每個(gè)業(yè)務(wù)SQL執(zhí)行時(shí)檢測拓普變化，決定是否替換掉真實(shí)的物理連接，參考上上圖。
而我們使用Maria驅(qū)動(dòng)每個(gè)創(chuàng)建的都是真實(shí)物理連接，如果要在物理連接上再抽象邏輯連接的話，工作量和實(shí)現(xiàn)都還是挺復(fù)雜的。
第一版：等待DNS切換的實(shí)現(xiàn)方案
在應(yīng)用程序中開啟一個(gè)線程每隔20s去拓普表中檢查當(dāng)前集群的寫節(jié)點(diǎn)是否發(fā)生變化，因?yàn)镈NS切換的時(shí)間大概就是20s左右。
SELECT SERVER_ID, SESSION_ID, LAST_UPDATE_TIMESTAMP, REPLICA_LAG_IN_MILLISECONDS
FROM information_schema.replica_host_status
WHERE time_to_sec(timediff(now(), LAST_UPDATE_TIMESTAMP)) <= 300
當(dāng)檢測到集群拓普發(fā)生變化時(shí)，獲取集群主節(jié)點(diǎn)端點(diǎn)HOST和當(dāng)前集群寫端點(diǎn)域名進(jìn)行探測，當(dāng)兩個(gè)端點(diǎn)指向相同IP時(shí)，認(rèn)為DNS切換完成，發(fā)出重建數(shù)據(jù)源事件，進(jìn)行數(shù)據(jù)源重建。（寫節(jié)點(diǎn)DNS切換基本維持在20s左右）
我們看下failover過程中DNS探測解析的日志(此過程和上圖不是在同一個(gè)failover中搜集的，時(shí)間會(huì)有偏差)
while true; do
/bin/echo 'infra-test-cluster.cluster-cbot6qvorv5g : ' $(date +%T) $(nslookup infra-test-cluster.rds.amazonaws.com | grep Address | grep -v '#53')
/bin/echo 'infra-test-cluster.cluster-ro-cbot6qvorv5g: ' $(date +%T) $(nslookup infra-test-cluster.rds.amazonaws.com | grep Address | grep -v '#53')
/bin/echo '---------------------------------------'
sleep 0.5 # 0.5 second
done
===============================================================================================================================================================================================
infra-test-cluster.cluster-cbot6qvorv5g : 16:37:33 Address: 10.57.51.213
infra-test-cluster.cluster-ro-cbot6qvorv5g: 16:37:33 Address: 10.57.52.67
---------------------------------------
infra-test-cluster.cluster-cbot6qvorv5g : 16:37:34 Address: 10.57.51.213
infra-test-cluster.cluster-ro-cbot6qvorv5g: 16:37:34 Address: 10.57.52.67
---------------------------------------
infra-test-cluster.cluster-cbot6qvorv5g : 16:37:35 Address: 10.57.52.67
infra-test-cluster.cluster-ro-cbot6qvorv5g: 16:37:35 Address: 10.57.52.67
---------------------------------------
中間相同省略……
---------------------------------------
infra-test-cluster.cluster-cbot6qvorv5g : 16:38:07 Address: 10.57.52.67
infra-test-cluster.cluster-ro-cbot6qvorv5g: 16:38:07 Address: 10.57.52.67
---------------------------------------
infra-test-cluster.cluster-cbot6qvorv5g : 16:38:08 Address: 10.57.52.67
infra-test-cluster.cluster-ro-cbot6qvorv5g: 16:38:13 Address: 10.57.51.213
---------------------------------------failover 過程中域名DNS解析總結(jié)
1. 【寫域名】轉(zhuǎn)移到【老讀庫】 -- 16:37:35
2. 此時(shí)間段讀寫域名都解析到【老讀庫】(后續(xù)晉升為新寫庫) -- ----
3. 【讀域名】轉(zhuǎn)移到【老寫庫】(后續(xù)降級為新讀庫) -- 16:38:13
此方案的問題：
- 1. DNS完成切換前會(huì)有寫業(yè)務(wù)的 read-only報(bào)錯(cuò)，持續(xù)在階段五，時(shí)間10~20s，主要看老讀庫重啟時(shí)長。
- 2. 從上面DNS探測的結(jié)果可以看出，會(huì)有持續(xù)較長一個(gè)階段讀寫域名解析到同一個(gè)實(shí)例上（老讀庫=新寫庫）。當(dāng)探測到寫庫域名切換時(shí)發(fā)起數(shù)據(jù)源重建，此時(shí)創(chuàng)建的讀連接會(huì)連接到新寫庫上。盡管不會(huì)對業(yè)務(wù)產(chǎn)生影響，但是讀寫分離的功能會(huì)持續(xù)30min失效。
如果是由于瞬時(shí)流量造成的寫庫故障發(fā)生failover，這樣切換到新寫庫上的話，除了正常的寫流量還會(huì)有所有的讀流量涌入，這樣將更快的把寫庫打垮，然后繼續(xù)failover……
那再把讀庫域名的切換加入到探測過程中呢？等待讀寫域名指向全部穩(wěn)定后再發(fā)起數(shù)據(jù)源重建事件怎樣？
首先，read-only的報(bào)錯(cuò)時(shí)長會(huì)拉長，因?yàn)橐瑫r(shí)等待讀寫域名的切換完成。
其次，如果我們只讀端點(diǎn)掛載多個(gè)讀實(shí)例的話，讀庫域名會(huì)在 Rout53 下每 5~30s 進(jìn)行輪訓(xùn)，固定不下來不好作為 DNS 切換完成的依據(jù)。
可以對只讀端點(diǎn)域名進(jìn)行多次探測，當(dāng)發(fā)現(xiàn)輪訓(xùn)結(jié)束后的IP數(shù)量等同于讀庫數(shù)量時(shí)認(rèn)為讀庫DNS切換完成。這個(gè)時(shí)間就太長了，并且還不確定是不是采用的輪詢算法。
此時(shí)，又想起了AWS智能驅(qū)動(dòng)…… 不幸的是它也沒有解決上述問題（上圖AWS-1.1.5版本測試結(jié)果）
第二版：依賴拓普結(jié)構(gòu)創(chuàng)建連接
上面看AWS故障轉(zhuǎn)移模塊代碼的時(shí)候發(fā)現(xiàn)，當(dāng)發(fā)生故障轉(zhuǎn)移時(shí)，邏輯連接不變，物理連接會(huì)通過拓普中的實(shí)例端點(diǎn)進(jìn)行連接替換。
要在Maria的連接中按照此方案實(shí)現(xiàn)的話，工作量太大、實(shí)現(xiàn)太復(fù)雜。
我們使用的是HikariCP連接池管理的鏈接生命周期，那如果我們在連接池創(chuàng)建連接時(shí)讓它按照我們給定的拓普去連接呢？
這樣的話，我們不僅解除了對DNS的解析依賴、還可以按照指定算法對讀庫進(jìn)行連接負(fù)載，同時(shí)還可以把故障影響范圍控制在數(shù)據(jù)庫實(shí)例重啟的時(shí)間范圍內(nèi)了?。?！
在連接池創(chuàng)建連接前，我們通過外部配置給定的集群讀/寫端點(diǎn)獲取當(dāng)前集群拓普結(jié)構(gòu)，在連接池創(chuàng)建連接的時(shí)候，寫庫連接我們分配主端點(diǎn)、從庫連接我們按照自己的分配算法（輪詢），將分配后的實(shí)例端點(diǎn)給到連接池，讓它按照我們給定的實(shí)例端點(diǎn)進(jìn)行連接的創(chuàng)建。
其中SwitchHostDatasource需要自己實(shí)現(xiàn)并給到Hikari，讓連接池使用我們提供的Datasource進(jìn)行連接的創(chuàng)建和維護(hù)。
經(jīng)驗(yàn)證，在 Failover 過程中， 僅影響當(dāng)前活躍連接在數(shù)據(jù)庫重啟過程中對應(yīng)的讀/寫業(yè)務(wù)，徹底消除 Failover 過程 DNS 帶來的read-only異常、也避免了 failover 后的連接傾斜現(xiàn)象，最小化的處理數(shù)據(jù)庫 failover 對應(yīng)用程序造成的影響。
巨人的肩膀：
https://aws.amazon.com/cn/blogs/china/be-vigilant-in-times-of-peace-amazon-aurora-fault-recovery-reduces-the-impact-of-dns-switching-on-applications/
