MongoDB备份与恢复实战(二)
前戏 老花: 话接上回, 我们今天总结下MongoDB分片集群部署模式下, 需要注意一些地方。 分布式全量备份和恢复实践 首先, 明确一点, mongdump/mongorestore支持热备份和热恢复。 为了提升备份工作流的并发性能, 我们可以将命令改为多个shard同时后台下发, 那么如何确保这些备份任务及时下发和反馈进度呢? 我们可以引入一个管控面, 这可以是一个组件暴露成接口, 也可以是k8s上的一个job或者cronjob, 定时去执行。 不管怎么说, 它理论上应该有这些功能: 异步下发指令。 监控指令完成。 执行下一个指令。 最终返回备份成功或者失败的状态, 以及一些其他附加信息。 我们把这个流程画成时序图。 全备时序图 主要步骤: 管控系统遍历每个Shard查找主节点:管控系统首先需要确定每个分片(Shard)的主节点。 并行执行mongodump异步命令:对于每个Shard,管控系统并行执行mongodump命令来备份数据。这里需要进行二次封装,确保每次执行后都能写入一个本地的status文件,记录备份的成功或失败状态。 轮询每个Shard上的状态文件:管控系统需要轮询每个Shard上的状态文件,检查备份是否成功。如果所有Shard都返回成功,则备份成功;如果存在失败或文件不存在,则需要继续轮询。 完成Shard备份后执行Configsvr备份:一旦所有Shard的备份都成功完成,管控系统将开始备份Configsvr。这同样需要查找Configsvr的主节点,然后执行备份。 Configsvr备份结果:Configsvr备份完成后,管控系统将收到备份结果,完成整个备份流程。 由此可见, 封装mongodump后的需要附加以下功能: 对接不同的灾备产品, 比如oss 对备份进行切分, 将备份上传到存储系统 上传备份数据到远程存储 全量恢复时序图 主要步骤: 管控系统遍历每个Shard查找主节点:管控系统首先需要确定每个分片(Shard)的主节点。 主节点上下载远程的存储文件:管控系统从远程存储下载备份文件。 重命名本地存储或发起本地备份:管控系统将下载的文件重命名或备份到本地存储,以便在恢复程序报错时支持数据回滚。 并行执行mongorestore异步命令:对于每个Shard,管控系统并行执行mongorestore命令来恢复数据。这里需要进行二次封装,确保每次执行后都能写入一个本地的status文件,记录恢复的成功或失败状态。 轮询每个Shard上的状态文件:管控系统需要轮询每个Shard上的状态文件,检查恢复是否成功。如果所有Shard都返回成功,则恢复成功;如果存在失败或文件不存在,则需要继续轮询。 完成Shard恢复后执行Configsvr恢复:一旦所有Shard的恢复都成功完成,管控系统将开始恢复Configsvr。这同样需要查找Configsvr的主节点,然后执行恢复。 Configsvr恢复结果:Configsvr恢复完成后,管控系统将收到恢复结果,完成整个恢复流程。 上面的时序新增了远程存储, 但是恢复的时候需要先下载到容器中, 可能导致数据有可能的三份膨胀: 下载到本地的远程的备份 本节点的原有备份数据 恢复过程中的数据 除了数据膨胀, 如果原先孵化pod的pvc存储不够, 可能会直接导致失败。 可能有人会这样想: 直接把本地数据删除, 然后远程下载解压不香吗? 还有人这样想, 我直接搞个新集群, 恢复完了, 再重命名回来? 第一个问题, 可以是可以, 但是服务就相当于宕机了, 而且恢复失败, 回滚也是比较费事了。第二个问题呢, 云原生里面的设计, 多租户隔离比较常见的, 可能这么操作比较不优雅。 ...