PolarDB：概述

支援無感秒切功能的PolarDB MySQL版版本如下：

• PolarDB MySQL版5.6版本，且核心小版本需為5.6.1.0.35及以上。

• PolarDB MySQL版5.7版本，且核心小版本需為5.7.1.0.24及以上。

• PolarDB MySQL版8.0.1版本，且核心小版本需為8.0.1.1.29及以上。

• PolarDB MySQL版8.0.2版本，且核心小版本需為8.0.2.2.12及以上。

• PolarDB MySQL版資料庫代理版本（Proxy）需為2.8.3及以上，查看和升級當前資料庫代理版本詳情請參見版本管理。

PolarDB無感秒切功能的核心技術如下：

• 全新的高可用系統VDS

  無感秒切開啟後，PolarDB會啟用VDS。VDS藉助PolarDB的共用儲存架構，可以實現叢集節點的自治管理、故障檢測和叢集選主。VDS架構說明如下：

  • VDS中每個計算節點有獨立的VDS線程，分為三種不同的角色：Leader、Follower和Observer。其中Leader對應PolarDB的主節點，Follower對應PolarDB的熱備節點，Observer對應PolarDB的唯讀節點。一般情況下，一個PolarDB叢集包含1個Leader、1個Follower和多個Observer。

  • VDS在共用儲存（PolarStore）上維護了兩個資料模組，分別是CAS Block和Polar Cluster Registry（簡稱PCR）。

    • CAS Block是PolarStore提供的支援Compare-And-Swap（簡稱CAS）操作的原子資料區塊。VDS基於CAS實現了分布式租約鎖，並在資料區塊中記錄了鎖持有人和租約時間等元資訊。PolarDB的主節點和熱備節點，通過續租和加鎖語義，完成故障探測和叢集選主。

    • PCR是一個儲存了PolarDB節點管理資訊的資料區塊，負責維護整個叢集的拓撲狀態。VDS中的Leader角色有PCR的寫入許可權，Follower和Observer角色只有隻讀許可權。當VDS中的Follower角色升級為Leader時，原來的Leader角色會自動降級為Follower，且只有最新的Leader角色才擁有共用儲存的寫入許可權。與此同時，PCR會重建拓撲。

  

  正常情況下，主節點對外提供讀寫服務，並通過VDS中的Leader定期續租。當主節點故障時，熱備切換流程如下：

  1. VDS Follower在租約超期之後會加鎖成功升級為Leader，從而使熱備節點升級為新的主節點。

  2. 故障的主節點恢複後，加鎖失敗，會自動降級為備節點。

  3. 在叢集選主流程結束後，PCR會將新的拓撲資訊廣播給所有的VDS Observer。這樣唯讀節點就能夠自動連接到新的主節點，並恢複LSN和Binlog等同步鏈路。

• 全域預熱系統

  熱備節點是特殊的唯讀節點，相較於普通的唯讀節點，它額外預留了小部分的cpu和記憶體資源來最佳化切換速度。全域預熱系統是熱備切換中最核心的模組，主要負責即時同步主節點的元資訊，將一些關鍵資料提前載入進記憶體，來提升未來潛在的升主切換速度。全域預熱系統包含四個模組： Buffer Pool、Undo、Redo和Binlog。

  • Buffer Pool

    Buffer Pool預熱模組會即時監控主節點Buffer Pool的LRU（Least Recently Used）鏈表，並將相關資訊發送給熱備節點。熱備節點會智能地選擇最熱的資料頁，並將它們提前批量載入到記憶體中，用來緩解唯讀節點切換為主節點後，Buffer Pool命中率大幅下降帶來的效能抖動。

  • Undo

    Undo預熱模組是對事務系統的預熱。在切換過程中，PolarDB需要從Undo Page中找出懸掛事務並進行復原。唯讀節點只會服務於分析類型的大查詢，而不會訪問主節點未提交的事務。因此，在切換流程中存在Undo Page的IO等待。熱備切換提前預熱Undo Page，通過Runtime Apply回放到最新版本，減少事務系統的恢復。

  • Redo

    Redo預熱模組會將熱備節點和唯讀節點的Redo日誌即時緩衝在記憶體的Redo Hash中。

  • Binlog

    如果叢集開啟了Binlog，切換過程中，處於Prepare狀態的InnoDB事務還依賴Binlog資訊來決策提交或者復原事務。對於大事務情境，完整讀取和解析最後一個Binlog檔案時，經常需要耗費數秒甚至數分鐘的時間。熱備節點通過後台線程，非同步地將最新的Binlog資料緩衝在IO Cache中，並提前進行解析，來徹底解決切換耗時問題。

  PolarDB支援熱備節點和普通備節點之間的動態轉換。在實際使用情境中，您可以選擇長期開啟一個熱備節點，或者選擇僅在變更配置、升降級的過程中短時間開啟熱備功能。為了節約成本，PolarDB支援配置不同規格的主節點和唯讀節點，但至少有一個和主節點同規格的唯讀節點作為災備，建議將這個節點配置為熱備節點。

• 串連保持和事務保持

  常規的主備切換或熱升級操作會對應用服務造成影響，導致串連閃斷、建立串連短暫失敗以及存量交易回復等問題，增加了應用開發的複雜性和風險。

  PolarDB支援串連保持功能。串連保持的原理是資料庫代理在應用程式和PolarDB之間，扮演了串連橋接的角色。當資料庫進行主備切換時，資料庫代理將新的後端串連（即資料庫代理和資料庫節點的串連）橋接到原有的前端串連（即應用程式和資料庫代理的串連）上，同時恢複之前的工作階段狀態，包括原來的系統變數、使用者變數和字元集編碼等資訊。

  串連保持功能只能作用於閒置串連，如果在切換瞬間，當前的會話有正在執行的事務，一方面資料庫代理無法從PolarDB中找回原有事務的上下文，另一方面新的主節點會將未提交的懸掛交易回復，釋放這些事務持有的行鎖。在這種情境下，串連保持就會失效，而PolarDB最新推出的事務保持功能可以解決這一問題。事務保持配合串連保持，可以實現對應用程式完全無感知的高可用切換。

  相比傳統的基於Binlog的邏輯複製，PolarDB是基於物理複製的架構，可以在熱備節點上重建與主節點完全一致的事務。

  假設應用程式完整的事務是begin-insert-update-commit，並開啟事務保持功能。事務開始執行時，PolarProxy在將SQL語句轉寄給主節點的同時，會緩衝最近執行的SQL語句。當INSERT操作在主節點執行成功後，PolarDB會自動儲存最近一條語句的Savepoint來作為事務資訊的一部分。通過Session Tracker將當前的會話資訊和事務資訊返回給PolarProxy，PolarProxy會將這些資料臨時儲存在內部緩衝中。其中，會話資訊用於串連保持，如字元集和使用者變數等資訊；事務資訊用於事務保持，如trx_id、undo_no等資訊。此外，事務資訊會通過一個單獨的RDMA鏈路，持續高效地同步到熱備中。如果後端資料庫開啟了Binlog，還會將每個事務對應的本地Binlog緩衝同步到熱備中。

  

  假設應用程式在PolarDB執行UPDATE的過程中，主節點出現故障。此時PolarProxy並不會立刻將底層的報錯傳給應用串連，而是將整個請求hold一段時間。熱備切換選主之後，新的主節點通過Redo Log構建出所有的未提交事務，並非同步等待未提交的事務，且暫時不進行復原。PolarProxy在探測到主備切換成功資訊後，會利用自身緩衝的會話資訊和事務資訊，藉助PolarDB的Attach Trx介面，橋接事務狀態。PolarDB會根據PolarProxy資訊，判斷相關的事務資訊是否有效。如果事務有效，會將事務資訊綁定到這個串連上，並復原至最後一條語句（即上文的UPDATE）對應undo_no的Savepoint中。

  當事務橋接成功後，PolarProxy就可以從SQL語句緩衝中，將最近一次未執行成功的UPDATE操作重新發送給新的主節點。從使用者角度來看，整個主備切換過程，應用程式只感知到一條執行時間變慢的UPDATE語句，但不會接收到任何串連報錯或事務報錯。