阿里云的PostgreSQL数据库恢复，让我丢脸，记住你了！

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

最近出了一档子事情，让我很丢脸，但并未生气。到底是怎么回事，我们来说说。

上个月有一个数据库要紧急恢复，PostgreSQL 13,一个7T的数据库。其实我们经常有一些需求恢复数据库进行压测，或者数据库恢复验证的审计要求。按照我们一贯的经验，7T的数据库如果要恢复，且产生一个新的实例的过程一般在4小时左右。

开发问大约多少时间，我们回答4小时左右，开发问能不能提前。我们回答这个不是我们决定的，这是阿里云PostgreSQL RDS 产品和你的数据库大小决定的，7T从备份数据从OSS拉下来，再到开始进行数据恢复到云盘，再到产生一个新的实例，以及各种云的实例的基础工作，是需要时间的。

然后我就打脸了，40多分钟一个基于备份数据恢复的新的实例就拉起来了，开发着急一直问，他也看见屏幕新的实例可以使用的提示，就问我。你不是说4个小时吗？ 怎么45分钟就起来了，弄得我上不来下不去。

我也问我自己，怎么这么快，以前哪里有这么快。然后我就开贴咨询阿里云到底是怎么回事。

他们给我一个图，我给照下来了，告诉我这就是快的主要原因，整体的数据库备份和恢复的架构调整了，同时POSTGRESQL RDS产品，也使用了存算分离的技术，让数据快速的恢复和POSTGRESQL RDS本身硬件配置并无关系。

大家可以注意他们给我的图中那个下面的字，1TB秒级挂载恢复，这里我也从其他的侧面了解了一下这个技术，这个技术是基于元数据即刻挂载技术。云端 CDM 的快： CDM 不会移动或复制整个数据块。它只恢复元数据 (Metadata)，创建一个虚拟卷（Virtual Volume），并将其挂载到目标计算实例上。这个过程几乎是瞬间完成的。

CDM 基于底层的写时复制 (Copy-on-Write, CoW) 或类似快照技术。它允许用户从任何一个备份时间点（快照）快速创建多个可读写的“克隆”副本（图中的 S1, S2, S3...），但这些克隆副本初期不占用额外存储空间。

而实际上基于这样的技术，与数据库的恢复速度和数据库的大小的关系就不大了。

同时我还问了一句，怎么有两个 region1,region2，后面他们解释主要的对数据库安全进行一个保证，比如机房 A 出现问题，那么数据库就全部失去了，在云上是不可能允许这样的事情发生，region2的是在另一个机房，对备份进行一个副本。

我说那全备恢复OK，快，这个道理我懂了，你们使用了CDM技术，可为什么基于时间点的PITR的速度你们也不慢，咱们POSTGRESQL都是单线程进行WAL日志的追偿，人家产品经理给我来了一句，我们有黑科技。

我一听黑科技，这意思就是不说呗，不告诉我呗！ 呵呵这能难得到我，我猜你们是把并行WAL日志读取恢复的技术用上了，好像他们有这个技术。

算了不打听了，反正快了就行，7T 45分钟一个实例拉起，我记住了，下次再问我就告诉他们1小时以内恢复完毕，恢复不完怎么办？ 那就“亢目普楞”他们。

MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项

MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"

MongoDB “升级项目”  大型连续剧(1)-- 可“生”可不升

MongoDB  大俗大雅，上来问分片真三俗 -- 4 分什么分

MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法

MongoDB 学习建模与设计思路--统计数据更新案例

MongoDB  大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB  大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通

MongoDB 年底活动，免费考试名额 7个公众号获得

MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模

数据库优化系列