1
OceanBase实践入门：高可用原理和容灾方案-云栖社区-阿里云.pdf
免费下载
2019/10/11 OceanBase实践入门：高可用原理和容灾方案-云栖社区-阿里云
https://yq.aliyun.com/articles/712723?spm=a2c4e.11163080.searchblog.174.2e052ec1vB796s 1/12
OceanBase实践入门：高可用原理和容灾方案-云栖社区-阿里云
mq4096 2019-08-05 18:04:22 浏览1090
本文内容是直播的文字稿，直播视频回放地址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落盘成功时这个事务就是可以提交的。所以有个极端案例
2019/10/11 OceanBase实践入门：高可用原理和容灾方案-云栖社区-阿里云
https://yq.aliyun.com/articles/712723?spm=a2c4e.11163080.searchblog.174.2e052ec1vB796s 2/12
就是主副本事务在提交时落盘失败，两个备副本却落盘成功。此后主备切换时这个事务会被恢复出来并提交。
这个情形在MySQL的主从同步上也可能存在，MySQL很大概率会因为这个出现主从不一致，修复过程也比较麻
烦。这个场景在OceanBase下首先会发生主备切换，老的主副本后来是备副本，在硬件问题解决后会自动从新
的备副本或者主副本那里同步缺失的日志。最终第三个成员也要把事务日志落盘。
自动切换方案分析
高可用通常都要求自动切换，否则对运维没有太大的价值。传统主备两副本架构下，当主备之间的网络中断时
对于是否切换可能会存在误判，导致备库也可能被激活为主库，出现双主和数据不一致。所以传统的双机房容
灾方案里负责做高可用切换的产品一定会在第三机房有个监测点，负责检测两机房可用性，以准确判断是哪个
机房不可用。
即使是用了一主多备的同步方案，在老主故障时选择新主时，依然要借助外部工具产品来判断和实施切换。这
个高可用产品自身的可用性就会显得至关重要。
OceanBase的三副本在主副本故障时会自动从剩下2个备副本里选择出一个新主，并保证这个新主一定是有全部
最新的事务日志。在没有故障的时候，OceanBase使用Paxos协议同步主副本的事务日志到备副本时就时刻在
保证每笔事务的日志都在三副本的多数成员里有落盘。所以当切换(选主)时，它一定能选出新的主且还不丢事务
日志。实际实现时，还会有些策略减少这个选举投票的时间以提高选举效率。不过OceanBase的三副本如果多
数成员都不可用，则无法选出新主，也不能恢复服务。
OceanBase的切换(选主)跟传统数据库不同，是以分区为粒度的。每个节点上可能有上千上万个分区，只有其
中角色是主副本的分区在该节点出现故障时才需要重新选举。并且是并行选举(当然并行度相对于要选举的分区
数来说还是太小，所以总体上也有个串行的特征)。所以，换个角度来说OceanBase里并没有主库或者备库的说
法。每个节点上可能既有部分数据的主副本，也有其他数据的备副本。默认只有主副本提供读写服务。
还有个特别的是OceanBase的选举机制是一直都在运行的。每个新主只能维持一个租约时间默认是10s。租约快
到期前要继续选举。只不过在没有故障的时候重新选举(有主选举)，会优先考虑老主当选。所以应用通常感知不
到这个。
of 12
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论