How do I fix a PostgreSQL 9.3 Slave that Cannot Keep Up with the Master?

You can configure replication slots for postgress to keep WAL segments for replica mentioned in such slot.

Read more at https://www.percona.com/blog/2018/11/30/postgresql-streaming-physical-replication-with-slots/

On master server run

SELECT pg_create_physical_replication_slot('standby_slot'); 

On slave server add next line to recovery.conf

primary_slot_name = 'standby_slot'

The two important options for dealing with the WAL for streaming replication:

• wal_keep_segments should be set high enough to allow a slave to catch up after a reasonable lag (e.g. high update volume, slave being offline, etc...).

• archive_mode enables WAL archiving which can be used to recover files older than wal_keep_segments provides. The slave servers simply need a method to retrieve the WAL segments. NFS is the simplest method, but anything from scp to http to tapes will work so long as it can be scripted.

  # on master
  archive_mode = on
  archive_command = 'cp %p /path_to/archive/%f' 
  
  # on slave
  restore_command = 'cp /path_to/archive/%f "%p"'
  

  When the slave can't pull the WAL segment directly from the master, it will attempt to use the restore_command to load it. You can configure the slave to automatically remove segments using the archive_cleanup_commandsetting.

If the slave comes to a situation where the next WAL segment it needs is missing from both the master and the archive, there will be no way to consistently recover the database. The only reasonable option then is to scrub the server and start again from a fresh pg_basebackup.