[ClusterLabs] PAF / PGSQLMS and wal_level ?

[Jehan-Guillaume de Rorthais]

On Wed, 13 Sep 2023 17:32:01 +0200
lejeczek via Users <users at clusterlabs.org> wrote:

> On 08/09/2023 17:29, Jehan-Guillaume de Rorthais wrote:
> > On Fri, 8 Sep 2023 16:52:53 +0200
> > lejeczek via Users <users at clusterlabs.org> wrote:
> >  
> >> Hi guys.
> >>
> >> Before I start fiddling and brake things I wonder if
> >> somebody knows if:
> >> pgSQL can work with: |wal_level = archive for PAF ?
> >> Or more general question with pertains to ||wal_level - can
> >> _barman_ be used with pgSQL "under" PAF?  
> > PAF needs "wal_level = replica" (or "hot_standby" on very old versions) so
> > it can have hot standbys where it can connects and query there status.
> >
> > Wal level "replica" includes the archive level, so you can set up archiving.
> >
> > Of course you can use barman or any other tools to manage your PITR Backups,
> > even when Pacemaker/PAF is looking at your instances. This is even the very
> > first step you should focus on during your journey to HA.
> >
> > Regards,  
> and with _barman_ specifically - is one method preferred, 
> recommended over another: streaming VS rsync - for/with PAF?

PAF doesn't need PITR, nor it has preferred a method for it. Both are not
related.

The PITR procedure and tooling you are setting up will help for disaster
recovery, PRA, not PCA. So feel free to choose the ones that help you achieve
**YOUR** RTO/RPO needs in case of disaster.

The only vaguely related subject between PAF and your PITR tooling is how fast
ans easily you'll be able to setup a standby from backups if needed.

Just avoid slots if possible, as WALs could quickly fill your filesystem if
something goes wrong and slots must keep WALs around. If you must use them, set
max_slot_wal_keep_size.

++