在实际数据库部署和运维过程中，根据数据库的重要程度，我们必须要考虑到数据库的机房级和城市级的容灾方案。因此，我也和大家一起看看oceanbase目前支持的比较成熟的几种场景下的容灾解决方案。
一、OceanBase容灾：同城三机房
1）同城3个机房组成一个集群（每个机房是一个Zone），机房间延迟一般在0.5～2ms之间；
2）机房级灾难时，剩余的两份副本依然是多数派，依然可以同步Redo-Log日志，保证RPO=0；
3）这种部署方式无法应对城市级的灾难。
二、OceanBase容灾：三地五中心五副本
1）部署方式：城市1和城市2分别部署2个zone，城市3部署1个zone，三个城市，组成一个5副本的集群；
2）任何一个IDC（1个zone）或者城市(region)的故障，依然构成多数派，可以确保RPO=0；
3）由于3份以上副本才能构成多数派，但每个城市最多只有2份副本，为降低时延，城市1和城市2应该离得较近，以降低同步Redo-Log的时延；
4）为降低成本，城市3可以只部署日志型副本（只有日志，参与选举投票和数据恢复，本身不能成为leader)；
三、OceanBase容灾：同城两机房“主-备”方案
同城三机房或者三地五中心的方案对基础设施要求太高。为了利旧企业现网的基础设施，OceanBase提供了同城两机房和两地三中心两种方案
1）同城市部署两套OceanBase集群，一个为主集群一个为备集群；
2）每个集群有自己单独的Paxos group，多副本一致性，每个集群都有多个zone；
3）“集群间”通过Redo-log做数据同步，形式上类似传统数据库“主从复制”模式；
4）有“异步同步”和“强同步”两种数据同步模式，类似Oracle DG中的“最大性能”和“最大保护”两种模式；
四、OceanBase容灾：两地三中心“主-备”方案：
1）主城市与备城市组成一个5副本的集群。主城市有两个机房(IDC)共5个zone，备城市1个机房3个zone；
2）任何IDC的故障，最多损失2份副本，剩余的3份副本依然满足多数派；
3）备用城市建设一个独立的3副本集群，做为一个备集群；
4）从主集群”异步同步“或者”强同步“到备集群，一旦主城市遭遇灾难，备城市可以接管业务。
具体各容灾方案的实施细节，我会在后续的文章中发布或者在此文中更新，敬请期待！
