本文总结了过去一年跟客户交流过程中积累的OceanBase相关的令客户费解的问题。即使是传统数据库DBA，初期理解这些问题也不容易。对OceanBase感兴趣的朋友也可以看看。如有错误，欢迎指正！
Q. OceanBase是内存数据库吗？
A. OceanBase的内存主要有两大块：一部分是block cache，存放从磁盘读入的基线数据，在内存里只读(不修改)；另外一部分内存存放增量(memtable)。OceanBase的数据写逻辑是内存里记录增量，所以内存脏块产生速度相比传统数据库而言很慢。当增量内存有一定规模的时候，脏块可以在内存里存放很久不落盘，以及增量内存可以容纳更多的脏块。这就是OceanBase被传为内存数据库的原因。增量内存脏块到一定比例时会发生minor freeze事件，随后部分脏块会临时写到磁盘上数据文件中以释放增量内存。默认每天会触发一次major freeze事件，将增量内存中的增量数据(脏块)和对应的基线数据在内存中合并然后写出到数据文件里，增量内存也释放了很多。
更多详情请参考《产品模块原理系列 |OceanBase内存管理原理解析》。
Q. OceanBase宕机丢数据吗？
A. 虽然OceanBase的增量在内存里，宕机时这部份增量数据却并不会丢失。因为这部份增量数据也是受事务日志(OceanBase里叫clog)保护的，后面可以恢复出来。OceanBase的写遵循Write Ahead Logging策略。事务提交的时候生成clog，clog会写入到本地磁盘和发送到其他对应节点。OceanBase里拥有clog的节点至少有三个(奇数)，并且保证每笔事务只有一半以上成员将clog落盘成功了该事务才算提交成功。所以OceanBase节点宕机时，该节点上的增量数据(已提交成功部分)是不会丢失的。此外，节点宕机后，原本该节点上提供读写服务的那部份分区(即数据)的访问会有其他节点接替，OceanBase保证新的节点拥有该分区的全部数据。这涉及到“三副本”的概念。
更多详情请参考《揭开数据库RPO等于0的秘密（下）》。
Q. OceanBase三副本是什么？
A. 传统ORACLE数据库单实例即可运行，为了高可用和容灾，通常会使用Dataguard技术再搭一个物理备库(实例)，并保持同步。Dataguard架构就是两副本，意为业务数据有两份。如果有两个备库，那就是三副本。OceanBase的单节点也可以运行，只限于测试。生产环境里，OceanBase至少要有三个节点，通常业务数据也会有三份，即三副本。
往小了说，OceanBase里表示数据的是分区，分区是表的子集。一个普通表就是一个分区，一个分区表会有很多分区。每个分区在整个集群里通常会有三份一模一样的数据，也就是三个副本。内容虽然一样，角色会有区分，最多只有一个主副本(也叫Leader副本)，其他都是备副本(也叫Follower副本)。
再往大了说，在OceanBase集群里，会把机器分为三部分，每个部分是一个区域(Zone),一个OceanBase集群至少会有三个Zone。Zone描述的是机器分布特征，也可以理解为容灾特征。对于一个分区的三副本，一定是分布在三个Zone里；否则就没有容灾的效果。
Q. OceanBase主备怎么同步？是强一致吗？
A. ORACLE的Dataguard架构里主备是靠同步Redo日志或归档日志，同步的粒度是实例级别。OceanBase集群里机器通常没有主备之说，数据同步是发生在每个分区的主副本到备副本之间的。不同分区的主备同步是独立进行的。同一个分区(数据)的主副本位置不是固定的(但受策略控制)，只会出现在其中一个Zone的其中一台机器上，但是不同分区的主副本是可以位于不同Zone或者不同机器上。
假设集群总共只有三台机器(节点)，有三个分区，每个分区有三个副本。很显然每个机器上都有每个分区的副本。但是三个分区的主副本的位置并不固定。它们可以都在其中一台机器上，这就跟传统dataguard架构很像，纯粹的一主两备；它们也可以在三台机器上。每个分区的主副本都要把clog同步给自己的备副本，三台机器之间都会有数据同步流。这点不同于ORACLE的dataguard架构，也不同于MySQL的Master-Master双向同步。
主副本跟备副本之间的同步协议不是异步同步，也不是全同步，而是Paxos协议。分区的所有副本(包括主副本自身)会在clog落盘成功后发起投票，当多数派副本都表决clog落盘成功后，业务事务在主副本提交返回。这样一个机制保证以后如果任何一个成员副本出现故障时，都能从多数派副本中找到完整的clog并应用在新的主副本上，从而保证数据跟故障前完全一致。
更多详情请参考《揭开数据库RPO等于0的秘密（下）》。
Q. OceanBase支持多点写入吗？
A.在宏观层面，OceanBase的每个节点都可以接受读写请求，所以简单说OceanBase支持多点写入。但是对于每个分区的三副本，只有主副本可以提供读写服务，备副本默认是不能写也不会读的。虽然每个节点可以接受写请求，节点会在内部将请求路由到要修改的数据(分区)的主副本所在的节点内。所以在微观层面，每个分区都是单点写入的(只有主副本能接受写入)。
理解这个“多写”特征，就可以理解很多“异地多活”方案的本质。更多详情请参考《如何基于OceanBase构建应用和数据库的异地多活》。
Q. OceanBase的数据分布特点是什么？
A. OceanBase集群至少是三副本架构，所以通常每个表数据都会有三份。然后OceanBase还提供了分区表能力用于将一个表数据水平拆分到多个分区里，而每个分区又会有三副本落在三个Zone里。所以极端情况下，可能会看到一个大表的数据会在所有节点上都有一部分。反过来，有些普通表的数据就是一个分区，三副本最多会在三台机器出现，而不是在所有的机器里都出现。也就是说使用OceanBase并不意味着每份数据都会分布到所有的机器上。关键点是看表是否做分区以及表所属租户的资源单元是否分布到所有机器节点上。
分片和冗余技术在磁盘RAID策略里常见，在分布式数据库里也很常见。更多详情请参考《分布式数据库选型——数据水平拆分方案》。
Q. OceanBase主备切换怎么做？有守护进程吗？
A. OceanBase的三副本除了会做数据同步外还会定期进行选举(选举谁做主副本)。通常没有故障的情况下，老的主副本连任的概率会非常大。当老的主副本出现故障时，在下一轮选举投票中就缺席了，新的主副本就会选出。前提是分区所有副本中还有一半以上成员(三副本的一半以上即是2个副本)可以参与投票。
OceanBase的高可用能力是内在固有属性，不可剥夺。不依赖外部工具产品或者DBA介入。更多详情请参考《OceanBase实践入门：高可用原理和容灾方案》。
Q: OceanBase节点宕机影响是多大？
A: 如果宕机的节点上没有数据(分区)，或者有分区但是副本角色是备副本，则该节点宕机不会带来任何故障，也没有故障切换事件。但是如果节点的宕机导致一些分区的三副本缺一，剩下的多数派成员(两个副本)将会承担clog落盘的责任。如果其中一个备副本所在节点跟主副本所在节点的网络延时相比宕机节点跟主副本节点延时大，将会导致主副本上事务提交性能下降(即写性能下降)。
如果宕机的节点上有分区的主副本，相应的分区会重新在其他节点上选举出新的副本。时间在十几秒到三十多秒不等。切换是批量进行的。分区副本角色切换期间，应用对这个副本的读写会报错。
Q. OceanBase租户是什么？租户跟数据库什么关系？
A.OceanBase集群将一组机器的资源能力聚合为一个大的资源池，然后从中划分出不同大小资源的租户给业务使用。业务使用的是OceanBase租户。租户就是通常说的实例。不过OceanBase租户有两种兼容模式可选(ORACLE或MySQL)，租户创建的时候选中一种兼容模式。业务方使用租户的体验就跟使用ORACLE或者MySQL实例差不多。
业务方感知不到OceanBase集群，只能接触到租户(实例)。如果是ORACLE租户，可以在里面创建多个schema(对应多个用户)，指代数据库时需要指定schema名称；如果是MySQL租户，可以在里面创建多个database。指代数据库时就需要指定具体的database名称。
Q. OceanBase怎么在线扩容？对业务是否有影响？
A. 每个租户都有一个资源池，由一组指定规格的资源单元组成。租户如果能力不够就扩大资源单元规格或者增加资源单元数量。租户资源池扩容的前提是集群大资源池里还有资源余量。否则集群也要扩容。集群扩容的方式就是补充机器。通常是每个Zone里增加相同数目的机器。
OceanBase集群和租户的扩容就是几句简单的SQL命令，剩下的事情全部是数据库内部逻辑，同时业务也不需要停机，对业务基本没有影响。
OceanBase的在线弹性伸缩能力在分布式数据库里是非常优秀的，并经历过蚂蚁业务长期的检验(尤其是双11前后的扩容和缩容)。更多详情请参考《揭秘OceanBase的弹性伸缩和负载均衡原理》。
Q. OceanBase怎么做负载均衡？
A. OceanBase扩容后可能会引起负载均衡逻辑。OceanBase集群有很多租户，每个租户有大小不同的资源池(由不同规格的资源单元组成)。租户的数据(分区)在资源单元里，资源单元在节点里。OceanBase在集群层面会尽可能维持各个节点的资源单元数量和节点负载保持均衡，同时在租户层面又会尽可能维持租户各个资源单元内部分区的分布保持均衡。跟传统负载均衡通过控制流量转发策略的原理不同，OceanBase的负载均衡是通过改变节点内部资源单元的分布，以及资源单元内分区的分布 来间接调整各个节点的负载。
这种调整是缓慢的，异步的，不需要人工介入的。运维人员只需要指定一些影响负载均衡的策略即可。负载均衡具体是通过分区副本的迁移和角色切换来实现的，所以极端情况下会出现业务大事务(100ms以上)被中断(需要业务捕获异常并发起重试)。
除此之外，负载均衡基本上是“润物细无声”。更多详情请参考《揭秘OceanBase的弹性伸缩和负载均衡原理》。
Q. OceanBase是云数据库吗？跟云绑定吗？
A. OceanBase集群的多租户能提高运维人员对机器资源利用率，有着“按需分配”的思想，跟云数据库理念非常契合。可以说OceanBase很适合云数据库。
不过OceanBase的目标是通用的分布式关系型数据库，可以部署在普通的商业服务器(目前主要是x86架构，ARM架构还在测试)上。当然也可以部署在云环境，只是不会强绑定。
Q. OceanBase在笔记本上能跑吗？
A. OceanBase运行目前对资源的最低要求比较高，主要是内存资源。1.4版本的OB正常运行，单节点规格至少要在16G以上。2.x版本的OB单节点规格至少要在96G以上。加上还要三节点部署，严重妨碍了OceanBase在普通用户群体的推广。OceanBase在2020年将会推出很小规格(如4C8G)的版本，实现在笔记本上运行一个OB单节点的目标。当然单节点有些功能(如扩容、高可用等)就没有了。
Q. OceanBase异地容灾或多活怎么做？数据怎么同步？
A. OceanBase集群的三个Zone可以是同一个机架的三台服务器，或者三个机架，或者三个包间，或者三个机房。当这三个机房是跨城市部署的时候，这个就是异地容灾或多活。不管是同城三机房还是异地三机房，OceanBase的高可用、强一致、在线扩容和缩容的能力都适用。换句话说OceanBase一套集群就可以实现异地容灾或多活。
所以异地多机房之间的数据同步问题就是OceanBase内部分区的三副本之间的同步问题，数据库容灾切换问题就是分区的主副本角色切换问题。这些都不需要运维介入，也不依赖外部工具组件。
这里有个特殊情况就是双机房容灾。三副本在双机房环境下将不可避免的有个机房是少数派，当多数派所在机房故障时，Paxos协议将无法工作，OceanBase集群就没有可用性。此时就要回归到传统数据库主备集群同步方案。OceanBase目前也正在开发主备库功能。
更多详情请参考《如何基于OceanBase构建应用和数据库的异地多活》。
Q. OceanBase备份恢复怎么做？
A. 分布式数据库的备份是个难题，数据可能分布在多个机器上，备份出来的文件要求是同一个快照(版本)。OceanBase默认每天凌晨2点(时间可以设置)会触发一次major freeze，将内存中的增量和磁盘上的基线数据在内存中合并为一个统一的版本并写到磁盘文件上。所以OceanBase默认每天都会在所有节点的磁盘数据文件里生成一个全局一致的数据版本。
OceanBase的备份分为全量备份和增量备份。全量备份就是将最近一次major freeze生成的数据版本备份出来。备份介质目前只支持OSS云盘或者NAS盘。OceanBase的增量备份是备份增量clog，跟传统不同有两点。一是备份客户端是连接到OB集群里获取增量clog，不是备份clog文件。二是只要clog有更新，很快就会被备份出去(近似1秒)。
OceanBase备份程序的架构是分布式的，备份和恢复服务器都是可以水平扩展，所以也不用担心备份和恢复速度问题。有关备份恢复详情，请参考《最强保障！一文详解OceanBase数据库备份恢复的技术原理》。
Q. OCP是做什么的？
A. OceanBase集群规模最小是三个节点，最大规模目前有200多台。集群的维护工作量可能会很大。OceanBase提供了一个自动化运维平台(OCP)，可以通过这个平台自动化部署、升级、重启、扩容和缩容、下线等，还有性能采集、监控告警、备份恢复等。OCP的目标是绝大部分OceanBase运维工作都可以通过这个平台完成。安装OB之前首先要安装OCP。OCP也需要独立的服务器，用docker容器技术部署。OCP会有自己的元数据库，是一个独立的OB集群。生产环境这个OCP元数据库也需要三台服务器(跟OCP一样以docker容器形式存在，共用物理机)。
更多详情请参考《稳定易用！全面解读新一代OceanBase云平台》。
Q. 怎么把数据迁移到OceanBase上？
A. OceanBase的租户兼容ORACLE或MySQL，通常ORACLE或MySQL的数据可以平迁到OceanBase相应租户里。数据迁移的关键点是对ORACLE或MySQL增量的同步，OceanBase产品OMS可以解析ORACLE/MySQL的增量并实时同步到OceanBase，延迟可以做到秒级。对于DB2,OMS目前还只能支持开放平台上的DB2增量同步。
OMS产品定位跟OGG类似，但不同的一点是OMS支持切换和回滚。将当业务数据同步到OceanBase并切换到OceanBase后，OMS会把OceanBase增量再实时同步回源ORACLE或MySQL。如果业务想切换回去也是可以的。OMS在每次切换前会对两边数据库做一次数据全量比对。
有关数据迁移详情请参考《低风险高效率！看OceanBase迁移服务如何帮助客户完成从集中式到分布式的架构转型》。
Q. 蚂蚁用OceanBase后为什么还要分库分表？
A. OceanBase作为分布式数据库，自身是有水平拆分能力，具体就是通过分区的方式。蚂蚁业务在早期使用ORACLE的时候就做了很多垂直拆分和水平拆分的设计。其中水平拆分就是使用分库分表中间件加ORACLE。分库分表将一个业务数据拆分到N个ORACLE实例里，每个ORACLE实例只有部分数据，当出现性能问题或者故障的时候，可以将影响面控制在很低的比例下。此后去ORACLE的时候，基本就是从ORACLE平迁到OceanBase上，应用层沿用了之前的分库分表架构。
分库分表还有另外一个重要作用就是很方便应用自身实现数据库的快速弹性Failover，而不依赖数据库自身的Failover技术。ORACLE一次主备切换时间在几分钟到十几分钟，OceanBase节点故障切换时间在十几秒到几十秒，这些时间对核心交易业务来说都是难以承受的。应用在分库分表中间件基础上实现的FO设计可以做到几秒内就切换数据源。此外，蚂蚁的异地多活单元化设计也依赖分库分表中间件的能力。
有关应用的数据库Failover方案详情可以参考《支付宝去O的关键技术之一——数据库弹性路由》。
Q. OceanBase支持分布事务吗？为什么蚂蚁还要用分布式事务中间件？
A. OceanBase提供给业务使用的是租户(也叫实例)，租户支持事务，满足ACID特性。由于租户的数据可能分布在不同节点上，这个事务也就可能跨节点了就是分布式事务。OceanBase内部对分布式事务的定义是跨分区的事务，使用两阶段提交协议处理。如果事务跨分区但是没有跨节点，就优化为单机事务流程；如果跨节点了，就是两阶段提交流程。OceanBase对两阶段提交有做一些优化，所以性能比传统好很多。业务使用租户的时候不需要担心是分布式事务。
由于蚂蚁应用层使用了分库分表，OceanBase租户只是分库分表架构里的一个实例节点，当业务事务跨越了不同的OceanBase租户时(并且有可能是跨越不同的OceanBase集群)，这种情形就跟传统架构下事务跨越不同的ORACLE实例情况一样了，这个事务必须靠应用层通过两阶段提交去实现。传统的两阶段提交协议有严重的性能问题，蚂蚁自己实现了分布式事务中间件(DTX)，事务执行框架支持XA、TCC、FMT、SAGA等模式.
有关分布式事务的中间件解决方案原理详情可以参考《说说数据库事务和开发（下）—— 分布式事务》。
据可靠消息，OceanBase将会在年前在官网上放出OceanBase 2.2的最新测试版本，届时我会给大家分享 2.2的功能、安装、运维经验。敬请关注！
其他参考
- 从ORACLE/MySQL到OceanBase序列
- OceanBase实践入门技术序列
- OceanBase资料大汇总(20190720)
蚂蚁社招通道启动中，OB求贤若渴，欢迎推荐
