Store binary logs for point-in-time recovery

Point-in-time recovery functionality allows users to roll back the cluster to a specific transaction, time (or even skip a transaction in some cases). Technically, this feature involves continuously saving binary log updates to the backup storage. Point-in-time recovery is off by default and is supported by the Operator only with Percona XtraDB Cluster versions starting from 8.0.21-12.1.

To be used, it requires setting a number of keys in the pitr subsection under the backup section of the deploy/cr.yaml file:

• backup.pitr.enabled key should be set to true

• backup.pitr.storageName key should point to the name of the storage already configured in the storages subsection

  Note

  Both binlog and full backup should use s3-compatible storage to make point-in-time recovery work!

• timeBetweenUploads key specifies the number of seconds between running the binlog uploader.

The following example shows how the pitr subsection looks like:

backup:
  ...
  pitr:
    enabled: true
    storageName: s3-us-west
    timeBetweenUploads: 60

Note

Point-in-time recovery will be done for binlogs without any cluster-based filtering. Therefore it is recommended to use a separate storage, bucket, or directory to store binlogs for the cluster. Also, it is recommended to have empty bucket/directory which holds binlogs (with no binlogs or files from previous attempts or other clusters) when you enable point-in-time recovery.

Note

Purging binlogs before they are transferred to backup storage will break point-in-time recovery.

Get expert help

If you need assistance, visit the community forum for comprehensive and free database knowledge, or contact our Percona Database Experts for professional support and services. Join K8S Squad to benefit from early access to features and “ask me anything” sessions with the Experts.

Community Forum Get a Percona Expert Join K8S Squad

---

Last update: 2024-10-29