OceanBase 大多数情况下会以同城三机房架构进行部署，因此备份恢复服务器也应该进行多机房部署，以防止主或备机房网络脑裂或其他网络故障情况下，备份任务会受到影响。本文主要介绍主机房不可用情况下，如何做到任务接管。
适用版本
OceanBase V2.2.50 及以前使用逻辑备份恢复的版本。
基本方案
基本方案是在同城第一机房和第二机房中分别配置 AgentServer 备份服务器。
备份进程 AgentServer 没有状态，部署的时候采用多台以上的物理机器，当一台机器故障时，另外一台机器可以继续完成备份任务。此时只需要在新的机器上启动 AgentServer。
[root@hostname /]# sudo su admin [admin@hostname /]$ cd /home/admin/oceanbase [admin@hostname oceanbase]$ ./bin/agent.sh start_backup
增量备份说明
OceanBase 数据库的增量备份是一个持续的过程，任务在发起后会一直执行，不断地备份数据变更生成的事务日志，因此增量备份任务没有历史表，任务的状态记录在 inc_data_backup表中。除了任务的状态， inc_data_backup表中的另一个重要参数是增量备份位点 checkpoint，代表这个增量备份任务已经备份到的时间点，这是衡量增量备份任务进度以及是否正常运行的重要指标。
增量备份虽然与基线备份集成在一起，不需单独启动进程，但是发起备份任务需要单独执行。同时增量备份也是通过 RPC 接口来读取数据的，因此 AgentServer 也需要与 OceanBase 部署在同一网络中。
OceanBase 数据库的增量备份是逻辑备份，增量备份的数据所包含的用户数据的变更与 MySQL 的 binlog 类似，只包含了变化的内容，没有包含数据在内存或硬盘上的物理变更。
使用 AgentServer 快速接管增量备份任务
当第一机房发生故障时， 主机房 incbackupserver 进程会失败，备机房的 incbackupserver 进行实时增量任务扫描 ，当备节点发现增量备份任务有线程退出接管，那么备节点将会执行增量备份任务，启动 inc_backup work 进程，inc_backup 个数为 N+1 ，日常当备份任务被第一机房 agentserver 接管时，备节点 inc_backup.log 会有如下日志：
incbackupserver 会定期查询 MetaDB 中的任务控制表 inc_data_backup，获取任务后通过 RPC 调用读取 OceanBase 的 clog，然后对日志进行解析，按照事务组装成特定的格式后输出至备份介质。
inc_backup 接管时间默认为 10 分钟, 关联时间戳是元数据库表 inc_data_backup表中 lease_expired_time 字段，该字段直接影响备份接管时间。
当主机房发生故障时，备份 incbackupserver 的 inc_backup worker 进程会在备节点启动，拉取增量数据，如果想立即接管，暂时可以通过修改备份元数据库表进行操作：
obclient> UPDATE inc_data_backup SET lease_expire_time=now() ;