开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第12天，点击查看活动详情
@[toc]
第三章：OceanBase集群技术架构
3. 数据可靠及高可用
3.1 灾难恢复能力等级
系统发生故障（掉电、宕机、进程误杀等）时，业务如何考察系统的“高可用”能力 • RTO（Recovery Time Objective)恢复时间目标：在故障或灾难发生之后，数据库停止工作的最高可承受时间，这是一个最大可容忍时限，必须在此时限内恢复数据 RTO = 服务可用性 • RPO（Recovery Point Object)恢复点目标：这是一个过去的时间点，当灾难或紧急事件发生时，数据可以恢复到的时间点，是业务系统所能容忍的数据丢失量 RPO = 数据可靠性
| 灾难恢复能力等级 | RTO（恢复时间目标） | RPO（恢复点目标） |
|---|---|---|
| 1 | 2天以上 | 1天至7天 |
| 2 | 24小时以上 | 1天至7天 |
| 3 | 12小时以上 | 数小时至1天 |
| 4 | 数小时至2天 | 数小时至1天 |
| 5 | 数分钟至2天 | 0至30分钟 |
| 6 | 数分钟 | 0 |
OceanBase RPO=0 RTO<30秒，意味着当少数派故障时，OceanBase能够在30秒内恢复业务，且不会丢失任何数据。
3.2 OceanBase基于通用PC服务器提供高可用性
OceanBase依靠自身的软件能力，可以在易损的硬件基础上提供更高的可用性
通用服务器，使用服务器自身硬盘，无需外挂独立存储，无需Raid
3.3 少数派故障时自动实现服务接管，保证服务高可用
3.3.1 举例：Leader副本故障
• 假设Zone3-OB Server2故障，P7 Leader主副本无法正常提供服务 • 位于Zone1的P7 Follower从副本和Zone2的P7 Follower从副本将重新选出新的Leader，并接管业务 • 整个过程无需人工干预，自动完成 • Zone3-OB Server2故障恢复后，P7副本首先追平数据，数据追平后，继续参加Paxos组，一般情况下，该P7副本还会是主副本（以实现负载均衡）
3.3.2 举例：Follower从副本故障
• 假设Zone3-OB Server2故障，从副本（P5,P6,P8) 本来就不承接业务，剩下的2个副本依然满足多数派，依然可以正常提供业务，对业务无影响 • 待从副本所在服务器故障恢复后，追平数据后继续加入Paxos组后依然是从副本
3.4 OB Server进程异常后的处理策略
如果OB Server进程异常终止，通过通过server_permanent_offline_time参数的值来判定是否进行“临时线下”处理。
• 由于进程异常终止时间不长，异常进程可能很快就可以恢复，因此OceanBase暂时不做处理，以避免频繁的数据迁移
• 此时P5-P8只有两份副本，虽然依然满足多数派，可以保证RPO=0，但存在风险（如果再有服务器故障）
• OceanBase会将机器做“临时下线”处理，从其它zone的主副本中，将缺失的数据复制到本zone内剩余的机器上（需要有足够的资源），以维持副本个数
• 异常终止的observer进程恢复后会自动加入集群，如果已经做过“临时下线”处理，需要从本zone内其它机器上（或者其它zone内）将unit迁移过来
3.5 传统数据库与OceanBase高可用方案对比
| 技术实现 | 备故障情况 | 主故障情况 | |
|---|---|---|---|
| 传统数据库 | 主库+备库，主备之间用redo-log同步。通常采用“最大可用模式”，不能保证RPO=0。 | 正常情况下为“最大保护模式”，一旦备出现故障或者网络出现故障，主的Redo-Log无法同步到备，导致应用无法正常执行，用户无法接受；一般此时会切换到“最大性能模式”，即RedoLog采用异步同步模式，但此时RPO>0； | 一旦主出现故障故障，备机不能自动切换为主（避免出现两个主的脑裂情况），需要人工将备机变为主机，至少要半小时以上，RTO>30分钟； |
| OceanBase | 基于Paxos协议的典型三副本部署：数据强一致性、持续可用、主备自动切换、不停服务、不丢数据。 | 少数派备副本所在的机器故障后，虽然主副本无法收到这些备副本的响应，但可以收到其他备副本的响应，依然满足多数派强一致，不影响业务。RPO=0； | 主副本所在机器故障后，剩余的2个副本可以自动选举出新的主，新的主自动接管业务 |
3.6 OceanBase容灾：同城三机房
• 同城3个机房组成一个集群（每个机房是一个Zone），机房间延迟一般在0.5 ~ 2ms之间 • 机房级灾难时，剩余的两份副本依然是多数派，依然可以同步Redo-Log日志，保证RPO=0 • 但无法应对城市级的灾难
3.7 OceanBase容灾：三地五中心五副本
• 三个城市，组成一个5副本的集群
• 任何一个IDC或者城市的故障，依然构成多数派，可以确保RPO=0
• 由于3份以上副本才能构成多数派，但每个城市最多只有2份副本，为降低时延，城市1和城市2应该离得较近，以降低同步Redo-Log的时延
• 为降低成本，城市3可以只部署日志型副本（只有日志）
3.8 OceanBase容灾：同城两机房“主-备”方案
同城三机房或者三地五中心的方案对基础设施要求太高。为了利旧企业现网的基础设施，OceanBase提供了同城两机房和两地三中心两种方案
• 每个城市都部署一个OceanBase集群，一个为主集群一个为备集群；每个集群有自己单独的Paxos group，多副本一致性
• “集群间”通过Redo-log做数据同步，形式上类似传统数据库“主从复制”模式；有“异步同步”和“强同步”两种数据同步模式，类似ODD中的“最大性能”和“最大保护”两种模式
3.9 OceanBase容灾：两地三中心“主-备”方案
• 主城市与备城市组成一个5副本的集群。任何IDC的故障，最多损失2份副本，剩余的3份副本依然满足多数派
• 备用城市建设一个独立的3副本集群，做为一个备集群，从主集群”异步同步“或者”强同步“到备集群
• 一旦主城市遭遇灾难，备城市可以接管业务
3.10 小结：Paxos协议的工业性实现保障数据可靠性及服务可用性
3.10.1 严格的Paxos协议
• 多副本（ZONE）一致性协议，一主(leader)多从(follower) • “多数派”（>1/2）强一致
3.10.2 特性优势
• 多数派数据强一致性，可容忍任意少数派故障 • leader故障时服务自动切换，无需人工干预 • 可灵活应对单机故障、机房级灾难、城市级灾难，实现全方位容灾
3.10.3 技术价值
• 任意少数派故障保证RPO = 0；高负载压测亦不降级 • leader故障服务自动恢复，RTO < 30秒 • RTO、RPO显著优于传统主备数据库 • 可达到国际灾难恢复能力6级
