本文内容是直播的文字稿，直播視訊回放位址 https://tech.antfin.com/community/live/773 OceanBase的高可用可以做到自動故障切換和不丢一點資料，即使是異地多機房部署也是如此。這是OceanBase的特性之一。OceanBase的高可用機制是資料庫核心能力不可分割的一部分，且是常态運作不存在需要的時候才發現失效了。
高可用方案要點
通常對高可用的要求就是資料庫如果出問題了要能夠自動切換，并且切換後不丢資料。
能自動切換，服務恢複時間才有可能最短，衡量名額就是RTO。切換後服務恢複時，資料丢失多少，衡量名額就是RPO。分析一個高可用方案就從這兩點入手。
資料庫不丢資料的關鍵——事務日志
資料庫事務要滿足ACID特性，其中D就是持久化，其關鍵點就是事務日志的設計。事務日志必須先于資料修改前生成并落盤，即常說的Write-Ahead Logging(WAL)。資料修改通常不會立即落盤。事務日志除了能用于本機資料庫當機恢複外，還可以用于建構備援副本(即備庫)并保持主備同步。
然而不同資料庫在實作上面方案的細節上又不完全相同，導緻實際效果并不完全一樣，需要懂這個原理才能區分。比如說MySQL自身有兩套事務日志，即InnoDB的Redo日志和Server的Binlog日志。前者格式是記錄資料塊的變化，後者格式是記錄修改資料的SQL。前者記錄未送出事務的日志(因為InnoDB有UNDO)，而後者隻記錄已送出的事務日志。是以MySQL執行個體當機恢複時都有可能沒辦法保證兩套事務日志完全一緻，更不用說依賴Binlog做主從同步。如果MySQL是依賴Binlog做主從同步并且Binlog有可能不立即落盤，那麼這個同步方案就不能絕對保證不丢資料。
ORACLE的主備同步是傳輸事務日志(記錄實體塊的變化)，并且REDO都是及時落盤。是以ORACLE的當機恢複，主備切換隻要順利的話都是可以不丢資料。不過如果REDO日志有缺失的話就不能保證了。
是以需要一種機制保證事務日志的可靠性。僅僅在本機落盤成功并不算可靠，因為可能會因為硬體問題導緻無法擷取盤上的事務日志。最可靠的方式是本機事務在送出的時候把事務日志在備庫主機上也落盤成功，這種方案叫強同步。ORACLE的最大保護模式的備庫就是強同步。它有個弊端就是備庫必須可用，否則主庫也會拒絕提供服務。是以ORACLE會建議至少配置兩個最大保護模式的備庫。這樣隻要有一個備庫接收到主庫的事務日志并落盤成功主庫的事務即可傳回。MySQL仿照ORACLE提供了一個半同步的技術，但是它在備庫都不可用的時候會降級為異步同步而不是像ORACLE那樣讓主庫拒絕服務。ORACLE認為在最大保護模式下資料一緻性最重要，甯可不要可用性。而MySQL則把可用性放在資料一緻性前面。是以業務核心重要資料通常放在ORACLE比MySQL上更可靠。即使ORACLE也提供最大可用和最大性能同步模式，也不會改變這點。
OceanBase的事務也遵循日志先行原理，事務日志簡稱CLog。OceanBase沒有UNDO設計，CLog落盤隻包含要送出事務的日志，在事務送出環節CLog先落盤，OceanBase的資料修改不落盤(記憶體富餘的情況下會在很長一段時間内都不會落盤)。OceanBase的資料備援至少是三副本，角色上劃分為1個主副本2個備副本。事務送出時，主副本的CLog除了自己落盤外還會同時發往其他兩個備副本。跟ORACLE的最大保護機制不一樣的時候，OceanBase認為三個副本隻要有一半以上成員将CLog落盤成功時這個事務就是可以送出的。是以有個極端案例就是主副本事務在送出時落盤失敗，兩個備副本卻落盤成功。此後主備切換時這個事務會被恢複出來并送出。這個情形在MySQL的主從同步上也可能存在，MySQL很大機率會因為這個出現主從不一緻，修複過程也比較麻煩。這個場景在OceanBase下首先會發生主備切換，老的主副本後來是備副本，在硬體問題解決後會自動從新的備副本或者主副本那裡同步缺失的日志。最終第三個成員也要把事務日志落盤。
自動切換方案分析
高可用通常都要求自動切換，否則對運維沒有太大的價值。傳統主備兩副本架構下，當主備之間的網絡中斷時對于是否切換可能會存在誤判，導緻備庫也可能被激活為主庫，出現雙主和資料不一緻。是以傳統的雙機房容災方案裡負責做高可用切換的産品一定會在第三機房有個監測點，負責檢測兩機房可用性，以準确判斷是哪個機房不可用。
即使是用了一主多備的同步方案，在老主故障時選擇新主時，依然要借助外部工具産品來判斷和實施切換。這個高可用産品自身的可用性就會顯得至關重要。
OceanBase的三副本在主副本故障時會自動從剩下2個備副本裡選擇出一個新主，并保證這個新主一定是有全部最新的事務日志。在沒有故障的時候，OceanBase使用Paxos協定同步主副本的事務日志到備副本時就時刻在保證每筆事務的日志都在三副本的多數成員裡有落盤。是以當切換(選主)時，它一定能選出新的主且還不丢事務日志。實際實作時，還會有些政策減少這個選舉投票的時間以提高選舉效率。不過OceanBase的三副本如果多數成員都不可用，則無法選出新主，也不能恢複服務。
OceanBase的切換(選主)跟傳統資料庫不同，是以分區為粒度的。每個節點上可能有上千上萬個分區，隻有其中角色是主副本的分區在該節點出現故障時才需要重新選舉。并且是并行選舉(當然并行度相對于要選舉的分區數來說還是太小，是以總體上也有個串行的特征)。是以，換個角度來說OceanBase裡并沒有主庫或者備庫的說法。每個節點上可能既有部分資料的主副本，也有其他資料的備副本。預設隻有主副本提供讀寫服務。
還有個特别的是OceanBase的選舉機制是一直都在運作的。每個新主隻能維持一個租約時間預設是10s。租約快到期前要繼續選舉。隻不過在沒有故障的時候重新選舉(有主選舉)，會優先考慮老主當選。是以應用通常感覺不到這個。
用戶端路由切換
平常談論高可用方案時重點都是資料庫的主備切換，很少提及用戶端需要做什麼。站業務角度應用最好是什麼都不要做。這個要求是合理的。如果這個能實作那必然是其他環節有做過。比如說資料庫主備切換了，IP可能變了，應用怎麼連接配接到新主上。
傳統的解決方案有VIP技術、DNS技術或者借助負載均衡裝置(F5或LVS)做轉發。現在常用的方案都是在中間件環節對應用到資料庫的連接配接做一次轉發。類似代理一樣，實作的好的話應用隻需要跟代理建立連接配接，後端資料庫主備發生切換時，代理會自動維護到新主庫的連接配接。這樣對業務而言可以做到會話保持(連接配接不斷)。不過會話的事務狀态不一定能保持。如果事務未送出的時候發生主備切換，該事務通常還是會失敗復原掉。需要應用有重試邏輯。
OceanBase裡的OBProxy是分區的反向代理。應用隻需要連接配接OBProxy，OBProxy會根據SQL特點将請求轉發到相應的節點。OBProxy會将通路過的分區的位置資訊緩存起來。如果後端分區發生主備切換，OBProxy會在第一次轉發時擷取到OBServer的回報(如不命中)然後重新拉取分區位置資訊并更新自己的緩存資訊。
除了OBProxy可以路由外，OBServer節點也是可以路由SQL請求的。這種情況不會少見。因為OBProxy在轉發SQL的時候，會考慮将一個事務裡相關SQL都轉發到同一個節點上。這不可避免的導緻有些SQL可能就被發往非Leader副本所在節點，那麼就需要被二次轉發一下。這也是遠端SQL和分布式SQL執行計劃産生的原因。詳細情況可以檢視《從ORACLE/MySQL到OceanBase：資料通路代理》。
OceanBase的高可用方案案例分析
OceanBase當機切換分析
下面就以一個具體的OceanBase節點當機事件為例詳細分析來加深大家對OceanBase高可用的了解。
接着上圖。假設OBServer01 節點發生當機。此時隻有t1(p0)的通路會受影響，t3(p1)、t4(p1)都是備副本，不會有通路。
OceanBase會在t1(p0)租約到期(10s)前發起新的選舉，老主連任失敗表示不可用，那就走無主選舉流程。當t1(p0)在OBServer02上的副本變為主副本後，OBProxy在通路這個分區的時候也能感覺到這一變化自動維護一個到新節點的連接配接。對于業務而言，應用連接配接不會中斷。不過前面說了，此前業務事務如果沒有送出會出現報錯復原。
此後對于這些分區(t1(p0)，t3(p1),t4(p1) 就隻有兩個副本在運作了。這個是一個危險的狀态，OceanBase不會容忍這個狀态長期存在。它會等待節點OBServer01恢複，如果超過一段時間(預設是2小時)還沒還有恢複，OceanBase會将該節點狀态下線，并自動找到同一個Zone的其他節點OBServer04，在上面補齊這三個分區的副本數。
OceanBase隻讀副本
在傳統資料庫裡有個讀寫分離的方案，其中會有個隻讀備庫。在主庫故障期間，隻讀備庫還能提供純讀服務，以将業務故障影響降低到最小。在OceanBase裡，在SQL上使用Hint也可以通路備副本。不過更推薦的方案是在三副本之外增加一個隻讀副本。隻讀副本會在一個單獨的Zone裡(隻讀Zone)。
隻讀副本的特點是不能寫，隻提供弱一緻性讀(可以在應用會話級别設定，資料可能有延時)。并且隻讀副本不參與CLog可靠性投票。是以隻讀副本也可以部署在異地機房不影響業務讀寫性能。OceanBase隻讀副本還有個特殊的能力就是假如主副本和備副本都不可用的情況下，隻讀副本還可以單獨提供純讀服務，以将業務故障的影響降到最低。
OceanBase線上不停服機房異地搬遷
OceanBase的高可用特性還可以用于機房線上搬遷。線上搬遷指業務對資料庫通路不會出現中斷，也不需要申請停機維護時間。整個搬遷過程由OceanBase自己保障資料強一緻，OceanBase的高可用能力也不會受損。是以不用擔心資料庫機房搬遷會有 不可用 或者丢資料的風險。
OceanBase線上搬遷技術的奧秘是利用了OceanBase可以線上增加隻讀副本，以及隻讀副本和備副本可以線上進行角色切換。整個搬遷過程會先從三副本擴容到六副本，然後逐個轉換備副本和隻讀副本的角色，當備副本都轉到異地的時候，業務的寫性能會下降，是以這個環節會放在業務低峰期做但業務不需要停。這個時間點也不會持續很久，迅速的就可以進入下一個階段。最後OceanBase叢集再從六副本縮容到三副本。
OceanBase的容災/多活方案
OceanBase的特性決定了它非常适合做機房異地容災和多活方案。不同客戶實際機房特點、業務要求可能不完全一樣，OceanBase都可以提供針對性的解決方案。由于OceanBase機房容災方案相關的文章已經很多。這裡就簡單提一下。
在OceanBase的資源管理了，會有Zone概念。這個是容災機關的一個邏輯機關。它可以是一個資料中心，或者是一個機房包廂，或者是一個機櫃等。具體是什麼取決于客戶實際機房情況和部署設計。
OceanBase的Region是城市。當同城有2個機房的時候，其中一個主副本不可用時，同一個Region的另外一個Zone裡的備副本會優先當選為新主。這是一個本地化政策。
- 同城/兩地三中心三副本
如果不能接受單副本故障時性能下降則更新到下面五副本方案。
- 兩地三中心五副本
如果不能接受單機房故障時性能下降則更新到下面五副本方案。或者可以降級到三副本。
- 三地三中心五副本
OceanBase高可用測試建議
- 資料庫部署建議
OceanBase叢集最少三副本，1-1-1架構。建議用2-2-2架構，測試更全面一些。
隻讀副本的功能可選。OBProxy可以安裝在OBServer節點上或者應用伺服器上。
- 應用建議
如果有現成的應用，應用需要捕獲資料庫異常，需要自動重試邏輯。
如果沒有應用，可以用sysbench模拟。sysbench有個問題如果資料庫報錯(如主鍵沖突)就會退出。是以需要忽略一些資料庫錯誤号。如：
模拟資料庫當機可以直接kill -9殺掉observer程序，拔機器網線或者斷掉機器電源。
- 監控建議
OceanBase有自己的運維平台(OCP)，它需要額外三台機器資源部署(因為自身還有個中繼資料庫OB)。
如果沒有OCP的話，可以使用OceanBase自身的腳本dooba。通常在/home/admin/oceanbase/bin/下。它可以觀察各個節點的請求資訊。如果有請求表示上面有主副本被通路。
下圖就是運作sysbench讀寫測試時，三個OBServer節點都有讀寫請求。
殺掉 節點78的observer程序後，可以看到讀寫壓力都轉移到其他兩個節點上。
總結
OceanBase的多副本(奇數)設計，以及使用Paxos協定同步事務日志，是OceanBase高可用能做到自動切換(RTO約20s)和不丢資料(RPO=0)的關鍵。OceanBase在這個設計上還衍生出很多特性：如負載均衡和異地多活等。
我計劃的有關OceanBase實踐入門的三次直播就全部結束。大家也可以到恩墨的墨天輪平台檢視前期直播回放：
https://cs.enmotech.com/course/17相關PPT下載下傳位址：
- OB直播間01_手把手教你搭建高可用的OceanBase資料庫叢集
- OB直播間02_OceanBase負載均衡和彈性伸縮實踐原理
- OB直播間03_OceanBase高可用原理和示範
- 從ORACLE_MySQL到OceanBase入門
推薦閱讀
- OceanBase資料庫實踐入門——手動搭建OceanBase叢集
- 揭秘OceanBase的彈性伸縮和負載均衡原理
- 如何基于OceanBase建構應用和資料庫的異地多活
- 從ORACLE/MySQL到OceanBase：資料通路代理
- OceanBase資料大彙總(20190720)
更多分享敬請關注公衆号：obpilot，對OB有興趣還可以發送消息“加好友”進一步溝通。