关注公众号 ZhangChen-PDU 免费下载PDU工具社区版
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了！