支持無(wú)感秒切功能的PolarDB MySQL版版本如下：

• PolarDB MySQL版5.6版本，且內(nèi)核小版本需為5.6.1.0.35及以上。

• PolarDB MySQL版5.7版本，且內(nèi)核小版本需為5.7.1.0.24及以上。

• PolarDB MySQL版8.0.1版本，且內(nèi)核小版本需為8.0.1.1.29及以上。

• PolarDB MySQL版8.0.2版本，且內(nèi)核小版本需為8.0.2.2.12及以上。

• PolarDB MySQL版數(shù)據(jù)庫(kù)代理版本（Proxy）需為2.8.3及以上，查看和升級(jí)當(dāng)前數(shù)據(jù)庫(kù)代理版本詳情請(qǐng)參見(jiàn)版本管理。

PolarDB無(wú)感秒切功能的核心技術(shù)如下：

• 全新的高可用系統(tǒng)VDS

  無(wú)感秒切開(kāi)啟后，PolarDB會(huì)啟用VDS。VDS借助PolarDB的共享存儲(chǔ)架構(gòu)，可以實(shí)現(xiàn)集群節(jié)點(diǎn)的自治管理、故障檢測(cè)和集群選主。VDS架構(gòu)說(shuō)明如下：

  • VDS中每個(gè)計(jì)算節(jié)點(diǎn)有獨(dú)立的VDS線程，分為三種不同的角色：Leader、Follower和Observer。其中Leader對(duì)應(yīng)PolarDB的主節(jié)點(diǎn)，F(xiàn)ollower對(duì)應(yīng)PolarDB的熱備節(jié)點(diǎn)，Observer對(duì)應(yīng)PolarDB的只讀節(jié)點(diǎn)。一般情況下，一個(gè)PolarDB集群包含1個(gè)Leader、1個(gè)Follower和多個(gè)Observer。

  • VDS在共享存儲(chǔ)（PolarStore）上維護(hù)了兩個(gè)數(shù)據(jù)模塊，分別是CAS Block和Polar Cluster Registry（簡(jiǎn)稱(chēng)PCR）。

    • CAS Block是PolarStore提供的支持Compare-And-Swap（簡(jiǎn)稱(chēng)CAS）操作的原子數(shù)據(jù)塊。VDS基于CAS實(shí)現(xiàn)了分布式租約鎖，并在數(shù)據(jù)塊中記錄了鎖持有者和租約時(shí)間等元信息。PolarDB的主節(jié)點(diǎn)和熱備節(jié)點(diǎn)，通過(guò)續(xù)租和加鎖語(yǔ)義，完成故障探測(cè)和集群選主。

    • PCR是一個(gè)保存了PolarDB節(jié)點(diǎn)管理信息的數(shù)據(jù)塊，負(fù)責(zé)維護(hù)整個(gè)集群的拓?fù)錉顟B(tài)。VDS中的Leader角色有PCR的寫(xiě)入權(quán)限，F(xiàn)ollower和Observer角色只有只讀權(quán)限。當(dāng)VDS中的Follower角色升級(jí)為L(zhǎng)eader時(shí)，原來(lái)的Leader角色會(huì)自動(dòng)降級(jí)為Follower，且只有最新的Leader角色才擁有共享存儲(chǔ)的寫(xiě)入權(quán)限。與此同時(shí)，PCR會(huì)重建拓?fù)洹?/p>

  

  正常情況下，主節(jié)點(diǎn)對(duì)外提供讀寫(xiě)服務(wù)，并通過(guò)VDS中的Leader定期續(xù)租。當(dāng)主節(jié)點(diǎn)故障時(shí)，熱備切換流程如下：

  1. VDS Follower在租約超期之后會(huì)加鎖成功升級(jí)為L(zhǎng)eader，從而使熱備節(jié)點(diǎn)升級(jí)為新的主節(jié)點(diǎn)。

  2. 故障的主節(jié)點(diǎn)恢復(fù)后，加鎖失敗，會(huì)自動(dòng)降級(jí)為備節(jié)點(diǎn)。

  3. 在集群選主流程結(jié)束后，PCR會(huì)將新的拓?fù)湫畔V播給所有的VDS Observer。這樣只讀節(jié)點(diǎn)就能夠自動(dòng)連接到新的主節(jié)點(diǎn)，并恢復(fù)LSN和Binlog等同步鏈路。

• 全局預(yù)熱系統(tǒng)

  熱備節(jié)點(diǎn)是特殊的只讀節(jié)點(diǎn)，相較于普通的只讀節(jié)點(diǎn)，它額外預(yù)留了小部分的cpu和內(nèi)存資源來(lái)優(yōu)化切換速度。全局預(yù)熱系統(tǒng)是熱備切換中最核心的模塊，主要負(fù)責(zé)實(shí)時(shí)同步主節(jié)點(diǎn)的元信息，將一些關(guān)鍵數(shù)據(jù)提前加載進(jìn)內(nèi)存，來(lái)提升未來(lái)潛在的升主切換速度。全局預(yù)熱系統(tǒng)包含四個(gè)模塊： Buffer Pool、Undo、Redo和Binlog。

  • Buffer Pool

    Buffer Pool預(yù)熱模塊會(huì)實(shí)時(shí)監(jiān)控主節(jié)點(diǎn)Buffer Pool的LRU（Least Recently Used）鏈表，并將相關(guān)信息發(fā)送給熱備節(jié)點(diǎn)。熱備節(jié)點(diǎn)會(huì)智能地選擇最熱的數(shù)據(jù)頁(yè)，并將它們提前批量加載到內(nèi)存中，用來(lái)緩解只讀節(jié)點(diǎn)切換為主節(jié)點(diǎn)后，Buffer Pool命中率大幅下降帶來(lái)的性能抖動(dòng)。

  • Undo

    Undo預(yù)熱模塊是對(duì)事務(wù)系統(tǒng)的預(yù)熱。在切換過(guò)程中，PolarDB需要從Undo Page中找出懸掛事務(wù)并進(jìn)行回滾。只讀節(jié)點(diǎn)只會(huì)服務(wù)于分析類(lèi)型的大查詢(xún)，而不會(huì)訪問(wèn)主節(jié)點(diǎn)未提交的事務(wù)。因此，在切換流程中存在Undo Page的IO等待。熱備切換提前預(yù)熱Undo Page，通過(guò)Runtime Apply回放到最新版本，減少事務(wù)系統(tǒng)的恢復(fù)時(shí)間。

  • Redo

    Redo預(yù)熱模塊會(huì)將熱備節(jié)點(diǎn)和只讀節(jié)點(diǎn)的Redo日志實(shí)時(shí)緩存在內(nèi)存的Redo Hash中。

  • Binlog

    如果集群開(kāi)啟了Binlog，切換過(guò)程中，處于Prepare狀態(tài)的InnoDB事務(wù)還依賴(lài)Binlog信息來(lái)決策提交或者回滾事務(wù)。對(duì)于大事務(wù)場(chǎng)景，完整讀取和解析最后一個(gè)Binlog文件時(shí)，經(jīng)常需要耗費(fèi)數(shù)秒甚至數(shù)分鐘的時(shí)間。熱備節(jié)點(diǎn)通過(guò)后臺(tái)線程，異步地將最新的Binlog數(shù)據(jù)緩存在IO Cache中，并提前進(jìn)行解析，來(lái)徹底解決切換耗時(shí)問(wèn)題。

  PolarDB支持熱備節(jié)點(diǎn)和普通備節(jié)點(diǎn)之間的動(dòng)態(tài)轉(zhuǎn)換。在實(shí)際使用場(chǎng)景中，您可以選擇長(zhǎng)期開(kāi)啟一個(gè)熱備節(jié)點(diǎn)，或者選擇僅在變配、升降級(jí)的過(guò)程中短時(shí)間開(kāi)啟熱備功能。為了節(jié)約成本，PolarDB支持配置不同規(guī)格的主節(jié)點(diǎn)和只讀節(jié)點(diǎn)，但至少有一個(gè)和主節(jié)點(diǎn)同規(guī)格的只讀節(jié)點(diǎn)作為災(zāi)備，建議將這個(gè)節(jié)點(diǎn)配置為熱備節(jié)點(diǎn)。

• 連接保持和事務(wù)保持

  常規(guī)的主備切換或熱升級(jí)操作會(huì)對(duì)應(yīng)用服務(wù)造成影響，導(dǎo)致連接閃斷、新建連接短暫失敗以及存量事務(wù)回滾等問(wèn)題，增加了應(yīng)用開(kāi)發(fā)的復(fù)雜性和風(fēng)險(xiǎn)。

  PolarDB支持連接保持功能。連接保持的原理是數(shù)據(jù)庫(kù)代理在應(yīng)用程序和PolarDB之間，扮演了連接橋接的角色。當(dāng)數(shù)據(jù)庫(kù)進(jìn)行主備切換時(shí)，數(shù)據(jù)庫(kù)代理將新的后端連接（即數(shù)據(jù)庫(kù)代理和數(shù)據(jù)庫(kù)節(jié)點(diǎn)的連接）橋接到原有的前端連接（即應(yīng)用程序和數(shù)據(jù)庫(kù)代理的連接）上，同時(shí)恢復(fù)之前的會(huì)話狀態(tài)，包括原來(lái)的系統(tǒng)變量、用戶(hù)變量和字符集編碼等信息。

  連接保持功能只能作用于空閑的連接，如果在切換瞬間，當(dāng)前的會(huì)話有正在執(zhí)行的事務(wù)，一方面數(shù)據(jù)庫(kù)代理無(wú)法從PolarDB中找回原有事務(wù)的上下文，另一方面新的主節(jié)點(diǎn)會(huì)將未提交的懸掛事務(wù)回滾，釋放這些事務(wù)持有的行鎖。在這種場(chǎng)景下，連接保持就會(huì)失效，而PolarDB最新推出的事務(wù)保持功能可以解決這一問(wèn)題。事務(wù)保持配合連接保持，可以實(shí)現(xiàn)對(duì)應(yīng)用程序完全無(wú)感知的高可用切換。

  相比傳統(tǒng)的基于Binlog的邏輯復(fù)制，PolarDB是基于物理復(fù)制的架構(gòu)，可以在熱備節(jié)點(diǎn)上重建與主節(jié)點(diǎn)完全一致的事務(wù)。

  假設(shè)應(yīng)用程序完整的事務(wù)是begin-insert-update-commit，并開(kāi)啟事務(wù)保持功能。事務(wù)開(kāi)始執(zhí)行時(shí)，PolarProxy在將SQL語(yǔ)句轉(zhuǎn)發(fā)給主節(jié)點(diǎn)的同時(shí)，會(huì)緩存最近執(zhí)行的SQL語(yǔ)句。當(dāng)INSERT操作在主節(jié)點(diǎn)執(zhí)行成功后，PolarDB會(huì)自動(dòng)保存最近一條語(yǔ)句的Savepoint來(lái)作為事務(wù)信息的一部分。通過(guò)Session Tracker將當(dāng)前的會(huì)話信息和事務(wù)信息返回給PolarProxy，PolarProxy會(huì)將這些數(shù)據(jù)臨時(shí)保存在內(nèi)部緩存中。其中，會(huì)話信息用于連接保持，如字符集和用戶(hù)變量等信息；事務(wù)信息用于事務(wù)保持，如trx_id、undo_no等信息。此外，事務(wù)信息會(huì)通過(guò)一個(gè)單獨(dú)的RDMA鏈路，持續(xù)高效地同步到熱備中。如果后端數(shù)據(jù)庫(kù)開(kāi)啟了Binlog，還會(huì)將每個(gè)事務(wù)對(duì)應(yīng)的本地Binlog緩存同步到熱備中。

  

  假設(shè)應(yīng)用程序在PolarDB執(zhí)行UPDATE的過(guò)程中，主節(jié)點(diǎn)出現(xiàn)故障。此時(shí)PolarProxy并不會(huì)立刻將底層的報(bào)錯(cuò)傳給應(yīng)用連接，而是將整個(gè)請(qǐng)求hold一段時(shí)間。熱備切換選主之后，新的主節(jié)點(diǎn)通過(guò)Redo Log構(gòu)建出所有的未提交事務(wù)，并異步等待未提交的事務(wù)，且暫時(shí)不進(jìn)行回滾。PolarProxy在探測(cè)到主備切換成功信息后，會(huì)利用自身緩存的會(huì)話信息和事務(wù)信息，借助PolarDB的Attach Trx接口，橋接事務(wù)狀態(tài)。PolarDB會(huì)根據(jù)PolarProxy信息，判斷相關(guān)的事務(wù)信息是否有效。如果事務(wù)有效，會(huì)將事務(wù)信息綁定到這個(gè)連接上，并回滾至最后一條語(yǔ)句（即上文的UPDATE）對(duì)應(yīng)undo_no的Savepoint中。

  當(dāng)事務(wù)橋接成功后，PolarProxy就可以從SQL語(yǔ)句緩存中，將最近一次未執(zhí)行成功的UPDATE操作重新發(fā)送給新的主節(jié)點(diǎn)。從用戶(hù)角度來(lái)看，整個(gè)主備切換過(guò)程，應(yīng)用程序只感知到一條執(zhí)行時(shí)間變慢的UPDATE語(yǔ)句，但不會(huì)接收到任何連接報(bào)錯(cuò)或事務(wù)報(bào)錯(cuò)。