GoldenDB多组件协同备份机制：CM调度与共享目录数据同步解析

GoldenDB 备份恢复涉及各组件数据分布

GoldenDB 的备份恢复涉及多个组件的文件，是由 CM 通知备份，将某个集群的 Binlog 、Data 、元数据、活跃事务信息和 Sequence 全部进行备份，各个组件下备份的数据，通过挂载的方式同步到共享目录下，备份文件的存储路径整理如下图。

GoldenDB 备份报错排查流程

到对应组件用户下检查日志

1. 先到 Clustermanager.log 中找到这次操作，找到对应的 uuid (日志关键字 cm_backup/cm_restore ) 。
2. Grep “uuid” clustermanager.log 找到该次操作的全流程，确定哪个模块出现的问题，确定好模块后再到相应的模块查询出错原因。
3. 备份如果是 xtrabackup 失败，查看 Innodbbackup*.log 的日志，具体名称通过 dbagent.log 获得。
4. 恢复问题，如果是恢复脚本的问题查看 restore.log 。

全量备份与增量备份的区别

全量备份就是把集群内全部的 Binlog 、Data 、元数据、活跃事务信息和 Sequence 进行备份，增量备份内容即距离上一次全量备份产生变化的数据进行备份，增量备份依赖全量备份，使用最近的增量备份+最近一次全量备份数据，可以恢复到增量备份数据时刻的数据。

备份过程报无操作具体文件权限需要如何处理

备份过程会由管理节点 Clustermanager 对其他组件的数据进行操作。如果报无操作权限时，请在对应服务器检查操作权限，如果是权限问题，手动赋权解决。

能否单独使用增量备份进行恢复

全量备份、增量备份存在依赖关系，增量备份依赖全量备份，使用最近的增量备份+最近一次全量备份数据，在增量备份文件删除前，其所依赖的全量备份文件不能删除。

定时备份是否支持当天就生效

GoldenDB 提供了定时备份策略，策略在第二天进行生效。为了试用当天就生效的场景，在备份恢复界面-更多-调整，调整时间到当天即可让备份在当天生效。

管理节点出现切换，是否会对备份恢复业务产生影响

管理节点出现切换或者替换 License 等操作 ，正常不会触发备份恢复。在下面这两种情况下会触发定时备份：

• 当日备份计划已过，且备份失败;

• 当日备份计划已过，且没有备份。

备份管理下的 Binlog 备份和单独的 Binlog 备份有什么区别

备份管理下面的 Binlog 备份是用来备份开始时刻到备份结束时刻，这段时间区间内的 Binlog ，单独的 Binlog 备份适用在备份文件结束之后的 Binlog 。

在恢复过程选择的恢复时间是备份到开始时刻与备份结束时刻，只需要有前者选择的备份 Binlog 即可，选择恢复的时间在备份结束后的任意时刻，需要单独备份 Binlog 。