WAL archiving v1
WAL archiving is the process that feeds a WAL archive in EDB Postgres for Kubernetes.
Important
EDB Postgres for Kubernetes currently only supports WAL archives on object stores. Such WAL archives serve for both object store backups and volume snapshot backups.
The WAL archive is defined in the .spec.backup.barmanObjectStore
stanza of
a Cluster
resource. Please proceed with the same instructions you find in
the "Backup on object stores" section to set up
the WAL archive.
Info
Please refer to BarmanObjectStoreConfiguration
in the API reference for a full list of options.
If required, you can choose to compress WAL files as soon as they are uploaded and/or encrypt them:
You can configure the encryption directly in your bucket, and the operator will use it unless you override it in the cluster configuration.
PostgreSQL implements a sequential archiving scheme, where the
archive_command
will be executed sequentially for every WAL
segment to be archived.
Important
By default, EDB Postgres for Kubernetes sets archive_timeout
to 5min
, ensuring
that WAL files, even in case of low workloads, are closed and archived
at least every 5 minutes, providing a deterministic time-based value for
your Recovery Point Objective (RPO). Even though you change the value
of the archive_timeout
setting in the PostgreSQL configuration,
our experience suggests that the default value set by the operator is
suitable for most use cases.
When the bandwidth between the PostgreSQL instance and the object store allows archiving more than one WAL file in parallel, you can use the parallel WAL archiving feature of the instance manager like in the following example:
In the previous example, the instance manager optimizes the WAL archiving process by archiving in parallel at most eight ready WALs, including the one requested by PostgreSQL.
When PostgreSQL will request the archiving of a WAL that has already been archived by the instance manager as an optimization, that archival request will be just dismissed with a positive status.