MySQL Operator Recurrent Backups

MySQL operator provides effortless recurrent backups while keeping the cluster highly available.

In the Backups section we take backups on demand. However, a cluster can be configured to take recurrent backups. Also, a cluster can be initialized from an existing backup.

To be able to store backups, the secret defined under backupBucketSecretName must contain the credentials needed to access the storage provider(e.g GCS, AWS, etc.)

Setup recurrent backups for MySQL cluster

You need to set the backupBucketURL in the cluster spec as an URL like s3://BUCKET_NAME, and the secret with storage credentials (backupSecretName).

See the example below to configure a cluster that has recurrent backups that runs once per day at midnight. To schedule a backup set backupSchedule field that is under crontab format. For more details about CRON format can be found here . Keep in mind this CRON format takes a 6th argument for seconds.

apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
  name: my-cluster
spec:
  secretName: the-secret

  backupSchedule: "0 0 0 * * *"  # daily
  backupURL: gs://bucket_name/path/
  backupSecretName: backup-secret
  backupRemoteDeletePolicy: retain|delete

Crontab takes 6 arguments from the traditional 5. The additional argument is a seconds field. Some crontab examples and their predefined schedulers:

Entry Equivalent To Description
15 0 0 1 1 * @yearly (or @annually) Run once a year, midnight, Jan. 1st, 15th second
0 0 0 1 * * @monthly Run once a month, midnight, first of month, 0 second
0 0 0 * * 0 @weekly Run once a week, midnight between Sat/Sun, 0 second
0 0 0 * * * @daily (or @midnight) Run once a day, midnight, 0 second, 0 second
0 0 * * * * @hourly Run once an hour, beginning of hour, 0 second

See Also

Integrating mysql clusters into your own helm charts

How to integrate the MySQL operator with your application.

The MySQL Operator Upgrades

The steps to make in order to migrate the operator to a newer version of the MySQL operator.