OB從4.x.x版本開始提供了兩副本加仲裁節點的高可用架構，比對三副本架構可以將第三個zone（機房）的成本降到極低，僅需要一個小規格的虛擬機器即可。對於沒有三個資料副本部署要求的業務來說，可以節約三分之一的伺服器資源。因此對於同城多機房部署下的資料庫架構，三副本架構和兩副本加仲裁節點架構將成為後續主流的高可用架構。
那麼，對於資料庫的高可用架構來說，我們最關心的兩個指標RTO，RPO在兩副本仲裁高可用架構和三副本架構下有什麼區別呢？兩副本仲裁架構下，主副本切換是否會丟資料？
對於RTO，其實對應著分散式CAP理論中的A，Availability。三副本架構下官方文件給出的RTO是<8秒，我個人是對這個值有疑問的。按照OB官網的說明，無主選舉和新主上任的時間可以在8秒內完成，所以RTO小於8S，但是當主節點故障時，首先會等待租約到期，這個租約到期的時間是由叢集引數lease_time控制的，預設是10s。所以官方文件給出的這個RTO是沒有把故障檢測的時間算進去的，這個時間就是lease_time，所以我個人認為RTO在預設情況下應該是18s。也看到有人說這個租約到期時間是4秒，所以這個RTO目前還是存有疑問。仲裁高可用架構下官方文件給出的RTO是秒級，並沒有精確到多少秒。同樣RTO的時間也是故障檢測+無主選舉+新主上任，由於選舉模組同樣是透過paxos協議，並且新主上任的同樣也需要補全日誌、恢復未提交事務狀態、向root service彙報leader位置資訊、等待obproxy更新leader資訊等一系列操作。所以無主選舉+新主上任的時間應該是和三副本架構差不多的。關於故障檢測，透過仲裁節點完成，關於這部分的流程和原理在官網上並沒有找到太多資訊。兩副本仲裁高可用架構下，仲裁節點只是代替了全功能節點作為paxos成員組中的一員參與paxos選主，所以從這方面理解，RTO應該是差不多的。
對於RPO，其實對應著分散式CAP理論中的C，Consistency。三副本架構下，日誌同步需要經過paxos多數派投票透過，和MySQL MGR一樣，主節點提交事務時會往從節點同步日誌，只有收到多數派返回的確認，事務才能提交。所以毋庸置疑RPO=0。兩副本仲裁架構下，由於仲裁節點不同步日誌，不參與日誌多數派投票，那主節點就會等待從節點回復日誌確認訊息，事務才能提交，因此RPO也是0。如果從節點故障或者兩個副本之間網路出現問題，那麼主節點也不應該一直等待下去。因此，仲裁高可用下引入了一個新的引數arbitration_timeout，日誌流降級控制時間，預設5s。如果超過5s主節點沒有收到節點回復日誌確認訊息，那麼仲裁服務會自動執行日誌流降級流程，對沒有像leader回覆確認訊息的副本進行日誌流降級操作。所以兩副本仲裁架構是可以保證主副本發生故障時資料不丟，類似MySQL的半同步機制。MySQL裡面控制日誌同步降級的引數是rpl_semi_sync_master_timeout，預設為10s，就是說當主庫事務提交後需要等待從庫的收到確認，這個等待時延超過10s時，主從半同步複製退化為非同步複製。但是在實現機制上和MySQL還是不同的，OCEANBASE是透過仲裁服務對沒有及時向leader回覆確認訊息進行日誌流降級，而MySQL是主庫等待時間超過日誌同步降級引數控制的時間後，直接退化為非同步複製，事務提交不再等待從庫的確認訊息。
參考連結：
https://www.oceanbase.com/docs/
https://ask.oceanbase.com/t/topic/35603255?_gl=1*u4onfb*_ga*OTI5MjQwMS4xNjk3OTc1NDc2*_ga_T35KTM57DZ*MTcyNjk4ODg1NS4xNS4xLjE3MjY5ODkzNTQuMTguMC4w