从ORACLE/MySQL到OceanBase：备份&恢复
近期打算写一个【从ORACLE/MySQL到OceanBase】序列。本文是第五篇，介绍数据库备份和恢复。第一期直播回放请到：https://cs.enmotech.com/course/play/17 。
上篇文章《从ORACLE/MySQL到OceanBase：数据导出&导入》介绍的是数据导出和导入，通常也称为逻辑备份。本文说的是面向数据库运维人员的物理备份和恢复。有些方案把搭建备库这种也会称为一种备份，本质上也多是用物理备份和恢复搭建备库。
物理备份和恢复通常也有两种方法。一是停掉数据库，备份所有相关的文件。这个通常称为冷备。这样备份出来的文件如果原地再起实例，通常是可以继续使用的。这是所有数据库的基本能力。不过绝大部分客户的应用都不会接受停机备份，而要求是在线备份。本文说的就是数据库的在线备份和恢复。当然恢复的时候，如果是恢复到原实例上(即覆盖原实例)，原来的实例肯定要停掉。这个是不可避免的。
下面先分析ORACLE/MySQL的备份和恢复原理、使用特点，然后再看OceanBase的备份和恢复就好理解一些。
ORACLE的备份和恢复
ORACLE官方提供的备份工具就是RMAN。RMAN可以对ORACLE数据库进行备份和恢复并自动管理相关备份策略。RMAN运行环境通常至少包含两部分：
目标数据库(
Target Database)：即需要进行备份和恢复的数据库(也是实例)，通过rman target命令指定。目标可以是主库或者备库，通常是备库。RMAN客户端：安装有rman命令的节点。通常安装有oracle基本客户端的都有这个命令，在$ORACLE_HOME/bin/下，用于执行rman命令。
有的RMAN环境还会包含下面几个部分，这样功能更强大一些：
快速恢复区(
fast recovery area)：用于存放和管理备份和恢复相关文件，通过ORACLE参数DB_RECOVERY_FILE_DEST和DB_RECOVERY_FILE_DEST_SIZE设置。介质管理器：
RMAN与介质设备打交道所需要的应用程序。恢复目录(
recovery catalog)：一个单独的ORACLE数据库(实例)，用于存储RMAN所管理的多个目标数据库的元数据。
RMAN的功能非常丰富，可以备份数据库、表空间、表、归档日志等，可以指定一些命名规则(FORMAT)，标签(TAG)等管理备份文件。在恢复的时候可以自动查找相应的备份文件、归档备份文件，可以自动做目录转换。在ORACLE 11g以后，RMAN duplicate standby database命令可以一键搭建一个ORACLE备库。
RMAN的备份性能跟数据库的性能、网络、备份介质的性能有关，RMAN可以指定备份的并行任务数(会话)，可以设置一些参数。备份路径为目标数据库能访问的本地盘、NAS文件路径或者共享存储、磁带库等。
RMAN支持全量备份、增量备份以及单独备份归档日志。其中增量备份可以分为多个层级。从LEVEL 0级开始，可以在此基础上再构建LEVEL 1级备份，依次类推，以满足多元化的备份策略需求。丰富意味着复杂，有时候运维人员会选择备份归档日志来代替增量备份。不同的策略，备份所需要的时间和空间不一样，恢复的时候时间也不一样。
RMAN还可以单独校验备份的有效性，管理备份的保存时间，自动删除过期备份等。RMAN备份还有个特殊的作用是用于修复主库中的坏块，前提是备库中该块没有坏。
MySQL的备份和恢复
MySQL支持多种数据存储引擎，每个引擎自行提供相应数据的备份和恢复方法。这里以InnoDB为例。InnoDB存储引擎的开发者（Innobase公司）开发了一款名为ibbackup的商业备份软件，专门实现InnoDB存储引擎数据的在线物理备份功能。该软件可以在MySQL在线运行的状态下，对数据库中使用InnoDB存储引擎的表进行备份，不过仅限于使用InnoDB存储引擎的表。Percona公司开发了一个工具XtraBackup可以在线备份InnoDB，XtraDB和MyISAM表的数据。
Xtrabackup备份也支持全量和增量备份。在全量备份过程中，针对MyISAM表，为了取得一致性数据快照，会发一个命令：flush table with read lock尝试加一个全局读锁并关闭表。这个命令有可能被其他未提交事务或者大查询阻塞，或者导致从库复制延时扩大。当MyISAM表很多时，这个锁持有的时间更长。
Xtrabackup恢复的过程，通常会有三步：prepare、apply-log、copy-back或move_back ， 分别是还原数据文件并应用增量日志，然后将数据文件复制回目标实例目录。Xtrabackup支持全量和增量备份，可以恢复到历史上任意时间点。
Xtrabackup备份目标可以是主库或者备库，会备份相应主库(Master)和主从同步的位点，这个信息可以用于将恢复出来的实例跟已有实例搭建主从复制关系。由于MySQL的实例是主还是从完全取决于变量read_only的设置和应用的写入点，所以这里这个设置复制位点的逻辑有点复杂，很容易出错。
跟ORACLE备份恢复不同的是，MySQL备份恢复不支持元数据库。当有很多MySQL实例需要做备份恢复时，需要借助PaaS平台去管理。云数据库服务RDS就包含数据库的备份和恢复管理。
OceanBase的备份和恢复
分布式数据库备份的难点
分布式数据库跟集中式数据库最大的一个区别就是数据是分布在多个节点上。当发出备份命令时，跟集中式数据库一样，要求备份出来的数据是全局一致的。要做到这一点方法有多种。一是像ORACLE那样有一个全局的SCN可以获取一个一致性的快照版本，二是在备份的那一刻临时阻塞一下所有事务在相关实例的事务日志里打个标记。分布式数据库DRDS后来也支持了一致性备份就是用后者这个思路。
在OceanBase里，全局一致性快照功能是2.0版本才开始有的，1.x版本没有这个能力。实际上OceanBase的备份并没有利用这个“全局一致性快照”的能力，而是利用了自身另外一个特点做的。
OceanBase的基线备份和增量备份原理
OceanBase架构的一个特点就是数据写的时候不是直接在原始数据块上修改，而是以增量的方式记录在内存中。原始数据块称为基线版本，后续的增量块为增量版本。一个完整的读过程就是基线版本加多个增量版本。这个读的过程就有点像恢复的过程。OceanBase的增量版本通常都是在内存里不落盘，内存资源不够时会临时转储到磁盘上释放内存。OceanBase默认每天都会将内存中的增量跟相应的基线版本数据做一次大合并，然后写到磁盘上存储。这里写到磁盘上的数据版本特点就是同一个基线版本。也就是说即使没有涉及到OceanBase备份逻辑，OceanBase每天都会自然产生一个全局一致性的版本在磁盘上，或者说每天都会生成至少一个基线版本。有了这个基线版本，OceanBase的备份就很好做了，只需要将最近的一次基线版本的内容备份出来即可。至于增量备份就是解析基线版本之后的事务日志(Clog)并以特定格式存储。
此外，OceanBase默认至少是三副本，在备份的时候只需要备份一个副本的基线版本和增量日志即可。为了性能考虑，它优先备份备副本的内容，降低对主副本读写的影响。
OceanBase的备份文件目录的特点是会为每个基线版本和对应的增量生成两个文件夹，里面再按租户ID分为多个文件夹。最关键的数据基线备份文件最小粒度是分区。这是目前的特点。后期可能还会变化。
OceanBase的恢复也分为基线版本的还原和增量转SQL的应用。恢复基线版本的是以分区的粒度进行还原，可以设置一定的并行度控制对性能的影响。
OceanBase备份程序架构设计
OceanBase内核团队提供两个工具agentserver和agentrestore分别用于OceanBase的备份和恢复。那么备份恢复程序要做的就是告诉这两个工具备份和恢复目标以及相关参数了。这个交互的方式不像RMAN那样可以通过命令指定，但是像RMAN那样使用了一个元数据库。元数据库里会有基本的几个表用来存储要做基线备份和增量备份以及恢复的集群和租户及其节点信息。同时还有几个表存储备份和恢复的任务细节。agentserver和agentrestore进程会一直保持运行，读取元数据库里相关表，自动做备份或者恢复操作。本质上OceanBase的备份程序也是一个独立的PaaS平台，它目前是作为OceanBase运维平台(OCP)的一部分。
所以要手动测试OceanBase的备份和恢复就是要构造一个元数据库，还必须是一个OceanBase租户(MySQL模式)。然后向相关表里写入数据。这个过程初次使用很容易出错。OCP使用图形界面封装了这个配置过程，并提供相关备份恢复任务查看。
如果企业的OceanBase集群非常多或者集群规模非常大，备份可能不能在要求的时间内完成。OceanBase的备份程序可以支持部署多台备份服务器同时做备份任务，多个服务器并发备份时会有内部措施保护对于一个具体的集群或租户不会同时有2个备份任务。
当上面的备份策略设置成功后，就会创建以下几个备份作业。
其中前面7个调度分别是每周的每天调度时间，当该次任务执行后，调度时间会自动更新为下次执行时间。最后一个调度是备份状态更新任务，会一直存在。在备份被调度执行时，其中一步是启动增量备份(往增量备份配置表里初始化一笔记录)。由于agentserver进程一直在运行，所以OceanBase的增量备份也是近乎实时的运行，这个跟ORACLE/MySQL的增量备份是定时调度的不同。OceanBase的增量备份这个特点保证了OceanBase的备份文件可以恢复到历史任意时间点(当然前提是在最早的基线版本时间之后)。
在恢复的时候，目前是需要先手工找到基线备份文件，然后发起恢复，选择要恢复到的OB集群和时间点。
然后会提示选择恢复的租户。目前的功能还只支持恢复到一个新的租户上(不能跟现有租户及其资源池重名)。
相比备份，恢复的时间要长一些。
总结
客户业务从传统数据库迁移到OceanBase上，对风险多少总有点担忧。OceanBase集群自身的三副本提供了绝不丢数据的自动故障切换能力，这个可靠性已经很高，再加上支持分布式数据库的备份和恢复，整体使用风险就更低了。当然OceanBase备份和恢复的功能实际使用也还有需要继续完善的地方。敬请关注后续版本更新。
推荐阅读