PDU注定是为特殊场景而生的，一个月前，我终于等到了这个特殊场景的到来，十分骄傲地在此给各位分享。

客户场景

数据量为 1.5TB  的Postgresql数据库，版本为 16.7，包含 Postgis 3.2.8版本的空间数据。
现场问题为磁盘坏块导致数据字典损坏，数据库已无法打开，且备份也无法使用。

PDU紧急上阵

初始化数据

可以看到系统表中确实出现了许多页面损坏的报错，对于这种情况，PDU选择直接跳过损坏的页面，继续读取完好的数据字典。

适配过的gis类型，依然报错？

PDU此前已适配过 Postgis 3.5.2，因此我本以为此次数据救援只会是时间问题，但没想到出现了意外情况。

现场工作人员反馈程序出现了频繁的core dump和gis解析报错。

不应该呀，难道不同版本的gis之间差异这么大？

我只能临时关闭了gis数据类型的解析，并给 unload sch加上 断点续传功能。

可以预见此后一定会不断地出现模式解析到一半就中断报错的情况，我必须要保证PDU能从失败的表继续解析，而不是从头开始解析。

争分夺秒，分析原因

经过分析，发现是之前将gis字段解压缩函数 detoast_attr中的 VARATT_IS_EXTERNAL_ONDISK逻辑给注释掉了，导致没有通过toast获取真正的的gis数据，直接用toast指针来解析gis数据。

那指定失败呀

于是赶紧复用了之前的toast解析代码，顺利走通了解析，同时发现jsonb也有这个问题，于是一起给修复了。
终于，数据解析不再出现问题，接下来就交给PDU，静等结果。

表对象数量是否准确

需要救援的这个库存在着一个月之前还原的备份老库，老库的表对象和数据量与当前救援的这个库相差不多，是具有参考价值的。客户也担心PDU解析出来的表数量存在问题，因此特地让客户查了一下老库的表数量。

对比看看

首先前往老库查询了表对象的数量和toast对象的数量，分别是 14551和 14160,加起来是 28711个对象。

其次PDU解析出该库的pg_class表中toast对象+表对象的数量是 28891个

并且我也取消了对系统模式的过滤，整体模式数量和对应表数量如下图所示，第一行显示toast对象是 14238 个，那么表对象则应该是 28891-14238=14653 个，我们将第一行以外的所有表对象数量相加，正是 14653个。

也就是说，从三个角度来看
整体的数量：当前 28891 老库 28711；
表的数量：当前 14653 老库 14551；
toast的数量：当前 14238 老库 14160。
当前正在抽取的新库的数量都多于一个月前的老库，这是符合逻辑的。
并且新库中每个模式的表数量相加也与总数量一致，未有出现表数量缺失的情况。
因此可以判断，PDU对于每个模式以及对应表的解析是准确的。

最终结果

恢复效果

客户的服务器性能足够给力，在PDU的全力并发支持下，以最快的时间将数据全部导出，并且恢复到一个新的实例中。
在数据导入的过程中也发现了一些乱码和转义的报错问题，也都迅速解决。

感想

• 当初凭着一腔热血往前冲，把PDU开发了出来，翘首以盼某一天能真正实战。  真到了实战的那天，才知道真实生产环境的残酷，睡觉都害怕有报错消息，不过还好是周末，没有影响日常工作。
• 真正经过了实战之后，信心倍增，本次恢复除了简单的日期字符数值类型之外，还包含各种疑难杂症结构体类型，真是开发得头都要爆炸了。
• 最后想说，PDU！太diao了！