*作者：馬志宏 YashanDB高可用架構師
核心業務的規模化部署，本質上是對“高可用”的極致考驗，任何一層的故障都可能導致業務中斷、數據丟失，唯有構建覆蓋從客户端鏈接到底層存儲的全鏈路高可用體系，才能讓企業真正放心託付。
YashanDB V23.5以“驅動崖山共享集羣YAC全面邁向規模化商用”為核心定位，對連接層、服務層、存儲層的高可用能力深度升級，並持續優化主備模式性能，既築牢故障防護的“安全網”，又打破性能損耗的“天花板”，為企業核心業務提供“業務永續、數據安全、性能穩定”的共享集羣解決方案。
圖1 崖山共享集羣YAC高可用總覽
連接層高可用升級
新增SCAN與VIP
過去，實現連接層高可用往往依賴於傳統方式，如同駕駛一輛“手動擋”汽車，客户端需要手動配置所有節點地址，故障切換慢，擴容運維繁瑣，嚴重影響業務連續性。YashanDB V23.5 引入了SCAN（單客户端訪問名稱）與VIP（虛擬IP）兩大機制，實現了從“手動擋”到“自動駕駛”的體驗躍遷，也是國內首個實現類Oracle SCAN機制的數據庫產品。
一、VIP實現“自動擋”式的故障切換
- 傳統連接方式：通過TAF+多IP的方式實現連接的自動故障轉移，但存在明顯缺點——每次連接都會嘗試重連故障節點，失敗後才能連接到存活節點，整個過程耗時較長。
- VIP方式：當服務器故障時會快速觸發VIP漂移，將連接轉移至可用節點。即使有服務器故障，新的連接也能直接連接到存活節點，不用經歷TAF試錯步驟，連接速度更快，保障業務快速恢復。
二、SCAN提供“自動駕駛”級別體驗
之前的連接方式還存在兩個突出問題：一是擴容時需要手動更新客户端配置，才能讓客户端訪問到新增的實例，維護成本高；二是負載均衡依賴於應用層，無法在連接層自動處理。
SCAN特性針對性解決了這些問題，進一步升級連接層高可用能力：
- 擴容透明化：客户端僅需配置一個SCAN名稱，新增實例後無需修改任何配置，後續連接可自動路由至新實例，顯著降低運維成本；
- 智能負載均衡：SCAN Listener由YCS（崖山集羣服務）進程接管，會定期收集所有實例的負載信息，並將連接路由至負載最低的數據庫實例，實現連接層的動態負載分發。
其接入流程清晰高效：JDBC首先通過DNS服務器獲取SCAN域名對應的SCAN VIP，連接至對應的SCAN listener，再由SCAN listener返回最優實例IP，最終完成二次連接建立。
圖2 SCAN透明接入示意圖
服務層高可用升級
全庫閃回+主備自動切換
一、新支持共享集羣全庫閃回
傳統數據庫恢復技術PITR（基於時間點恢復），通過全量數據庫備份方式進行整庫恢復，恢復時間長，且恢復效率受限於數據庫大小，無法滿足金融等領域“秒級恢復”的需求。
共享集羣全庫閃回技術實現比單機全庫閃回更復雜。在共享集羣架構下，每個實例都會維護自己的閃回日誌，也都有自己的閃回快照點。而全庫恢復的核心前提是“全局數據一致性”，如何讓所有閃回快照點保持全局一致，是共享集羣架構產品需突破的難題，之前僅有Oracle RAC實現了該特性。
圖3 全庫閃回示意圖
YashanDB V23.4 LTS已實現單機全庫閃回，V23.5基於閃回日誌快照點技術，率先在共享集羣架構中實現全庫閃回能力，成為國內首個具備該能力的數據庫產品，可廣泛應用於誤操作、備庫演練、業務升級預驗證等場景，大幅降低核心業務系統的運維成本與操作風險。具體實現原理如下：
1. 採用兩階段算法生成快照點，保證多實例一致性
- 階段1：選舉協調者實例，向集羣內所有實例（含自身）發送廣播，請求啓動Redo屏障（暫停數據頁修改日誌寫入），並收集各實例返回的當前SCN（系統改變號）；
- 階段2：協調者彙總所有SCN後，廣播統一的全局SCN，指令所有實例刷新本地SCN、生成閃回快照點，隨後解除Redo屏障。
該機制強制所有實例的閃回快照點對齊至同一SCN，從根源上保障了全庫閃回的全局數據一致性。
2. 優化閃回快照點機制，避免多線程並行修改衝突
YashanDB針對閃回性能做了優化，讓每個實例都可以啓動多個線程，並行應用閃回日誌。並且在應用閃回日誌的過程中，會根據目標SCN和閃回日誌SCN，自動過濾掉無需恢復的頁面版本。結合閃回快照點機制，可保障“同一頁面最多被修改一次”，避免多個線程併發修改同一頁面，各線程無需加鎖，恢復效率大幅提升。
圖4 兩階段閃回快照點算法示意圖
PITR與全庫閃回的技術對比可點擊《YashanDB V23.4 LTS全庫閃回新特性解讀》查看。
二、支持共享集羣主備自動切換
針對主集羣全實例故障、存儲故障等集羣級問題，崖山共享集羣YAC通過主備自動切換機制保障業務連續性，可以在主集羣全實例故障時，自動將備集羣升主，實現“故障自動接管、無需人工干預”。
- YashanDB使用OM（輕量級監控進程）對主備集羣狀態進行實時監控；
- 當主集羣所有實例故障，且備集羣無法連接主集羣時，OM自動下發failover命令，讓備集羣升主；
- 當故障的主集羣重啓後，會自動降為備集羣。
圖5 共享集羣主備示意圖
YashanDB提供“零丟失模式”和“普通模式”兩種共享集羣主備自動切換模式，適配不同業務對數據安全與可用性的平衡需求。
（1）零丟失模式：永遠保證數據不丟失，但有數據丟失風險時不可切換。
- 當主備正常連接時，會設置為最大保護模式運行，保證主集羣事務提交時，Redo已經發送到備集羣。當主集羣故障後，備集羣升主不會丟失任何數據。
- 如果主備連接不正常，此時會設置為最大可用模式，即使Redo沒有發送給備集羣，也不會阻塞主庫事務提交。但因為有數據丟失的風險，備集羣恢復Redo同步前，不能再自動切換升主。
（2）普通模式：永遠保證主備可切換，但有潛在數據丟失風險。
- 該模式下數據庫處於最大可用/最大性能模式。無論備集羣是否收到了主集羣所有Redo，只要主集羣故障，備集羣都會自動切換升主。
- 該模式下優先保證業務可用，但是如果發生連續多次故障和切換，可能會有數據丟失的風險。
存儲層高可用升級
支持YFS磁盤級故障處理
數據的底層安全是高可用體系的根基。YashanDB V23.5在已有數據塊級故障自動修復的基礎上，新增YFS（崖山文件系統）的磁盤級故障處理機制，通過“軟RAID（磁盤陣列）”技術全方位保障數據高可用。
- 傳統方案不足：存儲層高可用依賴物理RAID卡實現磁盤冗餘防護，採購與維護成本高昂；或是採用簡單的多副本冗餘機制，雖降低了硬件依賴，但缺乏智能的故障識別與切換能力。
- YashanDB：從自研的崖山文件系統YFS入手，基於故障組架構實現“軟RAID”技術，當磁盤出現離線等異常情況時，系統可智能識別故障狀態並自動切換至降級高可用模式。即便在硬件故障場景下，只要存在可用數據副本，YFS就能無縫切換運行模式，無需人工干預即可確保業務連續性，從底層築牢數據安全防線。
- 優化亮點：通過軟件層面的“軟RAID”技術，既能提供“硬軟”雙重保障能力，也能消除對高價硬件RAID的依賴，降低企業硬件採購成本；實現磁盤故障識別、副本切換的全流程自動化，業務側無感知。
圖6 崖山文件系統YFS軟RAID機制示意圖
主備模式性能提升
歸檔前後性能不降
高可用升級不會以犧牲性能為代價，YashanDB V23.5做了兩項重要性能優化，實現崖山共享集羣YAC主備模式性能提升，在開啓實時歸檔後性能基本無損耗。
（1）採用實時歸檔技術，對歸檔日誌IO優化，降低IO消耗
- 傳統方案不足：歸檔日誌是對redo日誌進行備份，在生成過程中會產生一次讀寫，影響數據庫性能；
- YashanDB：採用實時歸檔技術，在生成Redo日誌的同時，直接從Redo Buffer讀取日誌進行歸檔，省去讀IO環節，極大減少存儲IO消耗；如果Redo Buffer裏的日誌被淘汰了，歸檔線程可用繼續從Redo文件讀取日誌，直到Redo Buffer可用時再次從Redo Buffer中讀取。
- 優化亮點：優化後，YashanDB單機和共享集羣的主備性能都有顯著提升，尤其是共享集羣模式下，性能提升20%以上。
圖7 實時歸檔示意圖
（2）支持備庫回放預讀，對回放性能優化，提升同步效率
- 傳統方案不足：備庫回放性能對RTO和查詢延遲影響大，如果回放性能跟不上，備庫的Redo日誌會持續積累，導致RTO越來越大，嚴重影響主備高可用性能。
- YashanDB：此前已實現多線程並行回放的優化，將性能瓶頸從CPU轉移至IO——磁盤延遲越高，IO對回放性能的影響越明顯。為此，YashanDB創新實現備庫回放預讀能力，通過三級流水線將“Redo分析，頁面預讀，Redo回放”串聯起來；藉助多線程預讀與IO合併技術，提前將所需頁面加載至Buffer中，讓Redo回放變成一個純CPU操作，不再受IO影響，性能大幅提高。
- 優化亮點：備庫回放預讀技術讓崖山共享集羣YAC的備庫回放性能提升60%。且因為共享磁陣的IO延遲比本地SSD要高，該項技術對共享集羣收益更大。
圖8 備庫回放流水線示意圖
結語
全自研的技術底座賦予了崖山共享集羣YAC持續迭代的底氣：既實現了對國際主流產品的關鍵技術對標，又填補了國內共享集羣在高端商用場景的能力空白。如今，YAC已具備支撐金融、電信等核心業務規模化部署的全部條件，未來，YashanDB將持續深化高可用、高性能能力，以“穩定、高效、經濟、易用”為目標，為企業數字化轉型與信創替代提供更堅實的數據底座。
