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
标签：副本,架构,浅谈,RTO,OB,仲裁,日志,节点,RPO From： https://www.cnblogs.com/coygfly/p/18210025