pgBackRest VS pg_wait_sampling

This tutorial explains how to backup PostgreSQL database using pgBackRest and S3.

This isn't theoretical; many companies do PostgreSQL async 1:N physical replication, by using e.g. https://pgbackrest.org/ to have the primary push WAL segment files (a.k.a. "the last n milliseconds of packets" in the write-ahead log) as objects to S3, and then to have all read-replicas fetch from S3 and replay.

> You could do even better if you out-of-band signal the readiness so you do not need to poll while idle.

S3 and its clones have "object lifecycle notifications", where you can be informed by a push-based mechanism whenever a new object is put into the bucket.

But — what do you have to do, to get these notifications?

Subscribe to a message queue that S3 puts them into.

I haven't explored the territory in awhile but for bare-metal, you can't go wrong with Percona Distribution, which includes pgBackRest and a minimal web-ui. No one ever got fired for using Percona, etc.

Check out pgBackRest

I found this approach pretty cool in that regard: https://github.com/pgbackrest/pgbackrest

Something like PG barman or pg backrest could be good for you on the Postgres side.

Backups are limited. These days, pgbackrest is the go-to backup solution for PostgreSQL, and having used it I am very impressed so far. It provides full backups, differential, and incremental, as well as archiving of WAL segments for point in time recovery. It allows great flexibility in schedules and destinations for backups, how long to keep backups for, how many full backups. For example, you can have backups made to a local disk, and other backups to an external S3-compatible bucket, each with their own settings and schedules (e.g., scheduled via cron).

pg_wait_sampling together with pg_stat_statements gets you nearer to Oracle's ASH/AWR capabilities. PoWA can integrate that (and other interesting extensions) to generate some nice reports.

Another Another source of high CPU could be wait events. There are no built-in tools in Postgres to monitor them (unless RDS provides some). The approach I'd take on a "regular" Postgres installation is to sample the content of pg_stat_activity and then later analyze that after spikes have occurred. There are several extensions that already provide this, e.g. pg_profile or pg_wait_sampling or pgsentinel

pg_wait_sampling