0

The documentation at:

https://www.postgresql.org/docs/11/warm-standby.html#STREAMING-REPLICATION

Starts out by saying that:

"Streaming replication allows a standby server to stay more up-to-date than is possible with file-based log shipping. The standby connects to the primary, which streams WAL records to the standby as they're generated, without waiting for the WAL file to be filled."

Which sounds a lot like streaming replication is a replacement for WAL logfile-shipping. But a little later the instructions at 26.2.5 say:

"To use streaming replication, set up a file-based log-shipping standby server as described in Section 26.2. The step that turns a file-based log-shipping standby into streaming replication standby is setting primary_conninfo setting in the recovery.conf file to point to the primary server."

This sounds like a streaming-replication secondary must also be a logfile-shipping secondary, which seems redundant. I can understand that it's possible for the secondary to fall behind in replication so far that the master may delete WAL segments from it's xlog directory before they are replicated, and that is an argument for a WAL archive. But the documentation says that a "replication slot", apparently an indicator of the last WAL file processed by the secondary, will accomplish the same goal, I guess by telling the master to hold on to that and subsequent segments. At 26.2.5:

"If you use streaming replication without file-based continuous archiving, the server might recycle old WAL segments before the standby has received them. If this occurs, the standby will need to be reinitialized from a new base backup. You can avoid this by setting wal_keep_segments to a value large enough to ensure that WAL segments are not recycled too early, or by configuring a replication slot for the standby."

I'm in the midst of experiments, but any explanation would be appreciated.

Improve this question

1 Answer 1

Reset to default
2

Setting up the standby via a base backup is similar, and is not described in detail in both places. One place refers you to the other. That is all that is meant. You can have streaming without a WAL archive.

Improve this answer
3
  • Thank you jjanes! I had hoped that that was the case, but it's good to know that I'm working in the right direction.
    – Clovis_Sangrail
    Sep 4, 2019 at 11:55
  • Basically the minimum (best effort) version is that you configure the master to use big enough wal_keep_segments to keep enough WAL logs locally (on master) to have enough time to do both pg_basebackup and then replay the WAL logs on the streaming replica standby to get the whole system synchronized. The master must keep all logs from the start of the pg_basebackup until the replay is finished. If you setup WAL archive, you don't need to guess the right amount of segments to keep because replica will automatically fetch the missing WAL logs if master has already removed the local files.
    – Mikko Rantalainen
    Jun 8 at 13:30
  • If you don't want to create WAL archive, it's probably better idea to use replication slots which automate the amount of WAL segments to keep on master. And if you're running recent enough PostgreSQL (version 13 or newer), you can use max_slot_wal_keep_size to limit max disk usage for WAL logs and reduce local WAL log storage in most cases.
    – Mikko Rantalainen
    Jun 8 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.