我正在尝试转储一个巨大的数据库并压缩转储，以便不必等待数小时才能完成。
我通过以下方式转储数据库：
pg_dump -Fc -U -v | gzip > db$(date +%d-%m-%y_%H-%M).tar.gz
这给我留下了一个压缩的 tar 文件。我知道想要解压缩它以便仅获得 .tar 文件：
tar -xvf xxx.tar.gz
这给我留下了一条错误消息：这看起来不像 tar 存档文件
我的目标是通过 psql 导入它。我不明白我做错了什么——根据Postgres 文档在转储时，我可以使用 -Fc 以任何想要的格式转储？谢谢
答案1
这给我留下了一个压缩的 tar 文件
不。您正在使用，它为您提供了特定于和 的-Fc“自定义”文件格式。这不是 tar，因此您不会使用 gzip 调用来压缩 tar 文件。pg_dumppg_restore
此外，pg_dump 文档指出：
输出适合输入到 pg_restore 的自定义格式存档。与目录输出格式一起，这是最灵活的输出格式，因为它允许在恢复期间手动选择和重新排序已归档项目。默认情况下，此格式也是压缩的。
您的 gzip 尝试压缩已经压缩的内容。除了浪费时间之外，这没有多大作用。
事实上，在 下--compress=0..9，同一份文档告诉我们：
指定要使用的压缩级别。零意味着没有压缩。对于自定义和目录归档格式，这指定了各个表数据段的压缩，默认值是中等级别的压缩。对于纯文本输出，设置非零压缩级别会导致整个输出文件被压缩，就好像它是通过 gzip 提供的一样;但默认不压缩。 tar 存档格式目前根本不支持压缩。
所以，它已经使用了 gzip！无法减小已使用 gzip 进行 gzip 压缩的内容的大小。
你可以做的是使用
pg_dump -Fc -Z0 -U -v | zstd -5 > db$(date +%d-%m-%y_%H-%M).custom.zst
# ^ ^ ^ ^
# | | | \----- zstd compression level 5:
# | | | better than gzip --best,
# | | | but much, much faster
# | | \-------- use the zstd compressor
# | \-------------------- don't compress yourself
# \--------------------- custom format
因为，老实说，gzip是非常过时的。它很慢，扩展性不好，而且压缩率很糟糕。有许多更好的替代方案，但zstd允许进行广泛的速度/压缩比权衡，并且得到非常积极的维护并可用于所有平台。
警告：下面有轻微的咆哮！-5请注意，在压缩方面，您可以使用比; 更高的压缩设置。但越高，压缩速度就越慢。这实际上取决于您是否想尝试在时间与空间之间进行权衡-18，我经常选择-11for zstd，对于典型数据来说，它的速度大约是 的三分之二gzip --best，但往往会生成小 10% 的文件。zstd的压缩范围与速度权衡（如果您确实有太多空闲 CPU 时间并且关心 0.1% 更好的压缩比，则为-1或-18最多）比 gzip 的粒度更细，并且在现代机器上更有用，其中 zlib (-22它是 gzip 的基础）仅限于 32 kB 大小的窗口。因为，谁拥有超过 64 kB 的 RAM？每个人。到 2022 年，甚至我的烤箱也有超过 64 kB 的 RAM。因此，zstd 不会尝试使用非常小的字典构建窗口。这是它的压缩效果比 zlib/gzip 更好的简单原因之一。