Postgresql物理复制还是逻辑复制？

Question

我阅读了Postgres中逻辑复制槽和物理复制槽之间的区别。我对一些参数以及它们是如何使用的感到困惑。

1. 对于复制槽，我们有两个参数wal_sender_timeout和wal_keep_segments。对于第一个，如果复制连接空闲的时间超过wal_sender_timeout，postgres将断开复制槽。假设我们有一个逻辑复制槽，并且将wal_keep_segments设置为0，所有旧的wal日志都将从服务器中删除，那么如果复制服务器断开连接并再次尝试获取wal日志，它是否能够恢复/再次启动复制？同样的情况也会发生在物理复制槽中，还是wal_sender_timeout仅适用于逻辑复制槽？
2. 我托管了一个CloudSQL(GoogleCloudManaged)数据库实例，并创建了一个使用物理复制槽的读副本。在那里设置的参数是ms和wal_sender_timeout=60000中的wal_keep_segments=0。因此，如果读取副本在一段时间内失去了与主服务器的连接，那么它将无法恢复。但是我想我在这里遗漏了一些东西，因为网络中断已经发生了一段时间，但是在网络中断之后，复制仍然是正常的。

有人能把它清除掉吗。我正在阅读在线资源，但能够区分人们何时谈论逻辑复制和何时讨论物理复制。

我知道我可以使用连续归档来处理上述所有问题，但我只想从这些参数的角度来理解它。

Answer 1

WAL被保留，直到所有有效的时隙都被满足，而wal_segments/wal_segments_size被满足。如果您的所有复制都需要使用插槽，那么wal_keep_size就没有用途，应该为零。

如果wal接收器断开连接，则仍然维护WAL (除非设置并超过了max_slot_wal_keep_size )，等待它重新连接。

对于物理复制，使用插槽是可选的。如果您不使用插槽，那么您可以使用wal_ replicas /wal_ behind _size来给副本一个机会，以便在它们落后的情况下赶上它们。如果他们不能跟上这个数量的WAL，那么他们将被削减损失，并将不得不重新建立从零，以使他们回到网上。指定数量的WAL总是被保留的，即使没有副本实际需要它。

对于逻辑复制，必须使用插槽。因此，wal_keep_segments没有任何用途。

在实现了最新版本(v13) max_slot_wal_keep_size时，这允许在逻辑副本落后一定数量时将其断开。在这个系统中，只有当某物实际需要时，WAL的最大数量才会被保留。如果没有此设置，并且不进行仔细的监视，如果副本被永久断开或落后于无限大的数量，主服务器可能会填满其存储空间并停止工作。