问pg_basebackup花了太长时间

EN

正如Melkij所建议的那样，使用插槽应该可以防止所需的WAL被移除。然而，我怀疑pg_basebackup中存在一些计时错误，这使得它无论如何都会发生。我在“野外”见过几次，但在我尝试的时候却从未得到过它，这使得它很难被调查和解决。

如果您与max_slot_wal_keep_size发生冲突，就像Melkij所想的那样，我认为如果使用不同的错误消息pg_basebackup: error: unexpected termination of replication stream: FATAL: terminating connection due to administrator command，它就会失败，这就是为什么我认为您更有可能碰到了计时错误。当我碰到这个错误时，在备份启动后很快就会收到错误消息。但是很容易错过这条消息，然后它会继续复制整个数据目录，但最终还是失败了。

因此，一种选择是再试一次，在开始时注意错误消息，这样您就可以手动中止进程，而不是让它运行20个无用的小时。

虽然pg_basebackup当然很方便，但它在许多方面都不是很好。因此，您可能希望使用不同的方法进行独占备份，以复制数据，如rsync。pg_basebackup的压缩选项有点无用，它在未经压缩的光荣中通过网络传输数据，然后在客户端进行压缩。这与你想要站起来的复制品正好相反。rsync的-z选项将压缩数据以便传输，然后在数据到达时解压缩。这将取决于您的数据，但我看到它提高了传输速度在一个缓慢的网络15倍。

独占备份的另一个优点是，如果它被网络故障或其他什么东西打断，您可能可以使用-c选项获得rsync以获取它停止运行的位置，而pg_basebackup不会这样做。但是这一过程的效率将取决于你的数据在同一时间内已经翻了多少。

当然，您必须从打开WAL归档开始，或者使用pg_receivewal或诸如此类的方法来捕获初始副本期间生成的WAL，因为rsync不会像pg_basebackup尝试的那样为您做这件事。