大规模并行Postgres备份
内容提要
PlanetScale通过并行化技术实现大规模分片Postgres数据库的高效备份。系统为每个分片启动独立EC2实例，从S3恢复旧备份，混合使用S3和主节点回放WAL日志，最终加密存储新备份。此方法将32TB数据库备份时间从22小时缩短至2.8小时，并支持数据库扩容和节点替换，确保生产环境零影响。
延伸解读
并行备份的核心思路
文章强调，大规模并行备份的关键在于将任务分解到每个分片独立的临时实例上，而不是在主节点或副本上直接操作。这样既避免了备份过程对生产查询的影响，又通过并行处理大幅缩短了备份时间。例如，32TB的数据库在8个分片上并行备份，时间从22小时降至2.8小时，且分片越多，速度提升越明显。
混合WAL回放策略
为了在保证一致性的同时减少对主库的影响，系统采用混合方式回放WAL：大部分WAL从S3获取，因为主库只保留最近一小段时间的WAL，而S3中可能缺少最新几分钟的日志。因此，最后几分钟的变更直接从主库流式拉取，既避免了长时间占用主库资源，又确保了备份的实时性。
备份的日常用途
除了数据安全，备份在PlanetScale中还是日常运维的重要工具。例如，在数据库扩容或节点替换时，新节点会从最近的备份恢复数据，然后通过WAL追赶至最新状态，从而实现无缝切换。这体现了备份在分布式数据库管理中的核心作用，而不仅仅是灾难恢复的保险。
Q&A
PlanetScale如何实现大规模分片Postgres数据库的高效备份？
PlanetScale通过为每个分片启动独立的EC2实例，从S3恢复旧备份，然后混合使用S3和主节点回放WAL日志，最后加密存储新备份。这种并行化方法将32TB数据库的备份时间从22小时缩短至2.8小时。
为什么备份时要为每个分片启动新的EC2实例？
为了最小化对生产查询的影响。备份任务会消耗大量IOPS和计算资源，如果直接在primary或replica上执行，会影响生产流量。通过启动独立的EC2实例，可以将备份工作负载从生产节点上移开，确保生产环境零影响。
备份过程中如何回放WAL日志？
备份节点首先从S3恢复旧备份，然后从S3拉取大部分WAL日志进行回放，因为WAL会持续归档到S3。但由于最新WAL可能尚未归档，系统会从主节点直接流式传输最后几分钟的WAL，实现混合回放，确保备份数据与当前状态一致。
首次备份与后续备份有何不同？
首次备份使用pg_basebackup从每个分片的主节点复制数据到备份节点，然后配置复制并回放WAL，最后用wal-g上传到S3。后续备份则从S3恢复旧备份，再回放WAL，最后上传新备份。首次备份不直接使用pg_basebackup输出作为最终备份，而是用wal-g统一格式。
备份速度如何随分片数量扩展？
备份速度随分片数量线性扩展。例如，32TB数据库在8个分片上并行备份需要约2.8小时，而在32个分片上只需42分钟。100TB数据在100个分片上备份速度与1TB在单个分片上相当。
备份在数据库扩容和节点替换中扮演什么角色？
备份用于数据库扩容和节点替换。扩容时，新节点从S3拉取备份并回放WAL以同步数据；节点替换时，新实例从备份恢复并追赶WAL，然后作为副本加入。这确保了数据一致性和高可用性。
MySQL分片数据库的备份过程与Postgres有何不同？
MySQL分片数据库使用Vitess作为分片层，备份使用VTBackup，复制使用MySQL二进制日志，回放从主节点直接进行，而不是混合S3和主节点。整体流程类似，但工具和日志类型不同。
