从蒙戈DB迁移 Atlas到一个自办的复制品集 购买了我们的控制权 并削减我们的账单。
还悄悄地删除了我们不再思考的东西:阿特拉斯一直不断地为我们提供备份。
迁移后,普罗切斯塔的生产数据生活在一个单一的VPS上.
没有快照。
没有脱机副本。
一个,一个糟糕的迁移脚本, 或一个死盘会是它的结尾。
我们曾写过"备份",作为迁移类的后续任务,这是相当于银行金库上粘纸条的工程.
我们实际关心的要求比"备份数据库"要窄.
在我们这个尺度上,大多数真实世界的数据损失并不是硬件故障——它是一个写垃圾的部署,或者有人在没有过滤器的情况下运行更新. 14: 20的破坏发生时 恢复到昨晚无济于事 你注意到14: 50 我们需要恢复到一个任意的时刻,而不是一个夜晚的快照。
没有人提到这种限制:社区没有选择Percona备份, PBM提供物理备份——快速文件级副本,在几分钟后恢复,并勉强触摸正在运行的服务器.
它们通过聚合阶段打开备份光标来工作.
该阶段存在于为MongoDB服务的Percona服务器和MongoDB企业。
在MongoDB社区不存在,这是官方形象船。
因此,在社区,PBM只给你逻辑备份: 每一个文档通过 ,压缩,并运出出箱.
两种后果,两者都是被有意接受而不是后来发现的:备份在主机上花费CPU——加上单人复制机设置,读取器的卸载没有次要.
恢复插入文档并重建索引,因此恢复时间会随着数据大小而增长,比备份时间要快得多.
以我们目前的规模来说,是分钟,不是小时。
这也是最终可以证明将图像换成Percona Server的理由.
知道哪个约束会迫使下一次迁徙 比假装没有更值钱 我们已经建造了其中之一。
我们没有用它。
我保留了Mongopit,一个自办的MongoDB即时恢复工具。
它的架构与我们最终的形状相同: 对于一致的完整快照,一个守护进程尾随 oplog 并流出压缩的 BSON 片段到云层存储, 在破坏你一天的操作之前停止重播。
它运送GFS保留,一个还原预览,并作为单一多克编曲服务运行.
它通过rclone在Google Drive上存储备份.
这正是我们为PBM而达到的原因——我们希望将Cloudflare R2作为一等目标,这些原因值得说明,因为它们与Drive无关.
数据已经存在。
Prochesta通过S3 SDK服务用户从R2上传,接收并生成PDF.
同一个账户,同样的证书,同样的帐单, 同样的仪表板 我们已经检查了在一个事件。
添加Google Drive意味着第二家提供商,第二家服务账户,第二家在凌晨3点出现错误.
R2有零后退费,这是一个可靠性特征,而不是一行项目.
恢复排练将整个备份拉倒.
如果每个钻头都有带宽成本附加,钻头就悄悄地停止了发生——而未经排练的后援则是谣言.
我们希望练习的费用是零 所以永远没有理由跳过它。
对象存储语义为此工作击败了文件同步语义.
S3风格多段上传,可预计的API速率限制,以及平滑的密钥命名空间是无人看管的夜间工作想要的.
Drive服务账户带来了自己的业务纹理:每日传输上限,服务账户的共享驱动要求,以及API配额错误,作为失败的备份而非缓慢的备份而浮出水面.
PBM讲S3本地语,因此R2需要配置,而不是翻译层. rclone的S3后端 原则上可以指: mongopit at R2 —— 但这是工具的路径