Point-in-Time Recovery

As of version 1.4.0, the PolarDB-X Operator has rolled out support for point-in-time recovery (PITR), allowing you to restore your database to a specific moment. This guide walks you through the process of point-in-time recovery for PolarDB-X.

Prerequisites

1. Update the PolarDB-X Operator to version 1.4.0 or higher.
2. Ensure incremental log backup is set up and configured to enable PITR (this is supported by default).
3. There must be a full backup available prior to the target recovery timestamp.
4. Continuous incremental log files should exist from the time of the full backup to the target recovery point.

Recovering PolarDB-X Cluster Within the Same Kubernetes Cluster

apiVersion: polardbx.aliyun.com/v1
kind: PolarDBXCluster
metadata:
  name: pxc-pitr-restore   # Name of the restored cluster
spec:
  topology: # Cluster specifications
    nodes:
      cn:
        template:
          image: polardbx/galaxysql:latest
      dn:
        template:
          image: polardbx/galaxyengine:latest
  restore: # Specify the creation method of the cluster is recovery
    from:
      clusterName: polardb-x-2      # Name of the source PolarDB-X cluster
    time: "2023-03-20T02:06:46Z"    # The specific point in time for recovery

Write a yaml file for the recovery following the example provided, and initiate recovery with this command:

kubectl apply -f pxc-pitr-restore.yaml

Recovering PolarDB-X Cluster Cross Kubernetes Cluster

apiVersion: polardbx.aliyun.com/v1
kind: PolarDBXCluster
metadata:
  name: pxc-pitr-restore-cross   # Name of the restored cluster
spec:
  topology: # Cluster specification
    nodes:
      cn:
        template:
          image: polardbx/galaxysql:latest
      dn:
        template:
          image: polardbx/galaxyengine:latest 
  restore:  # Specify the creation method of the cluster is recovery
    storageProvider:   # Storage configuration for the data backup set
      storageName: xxx 
      sink: xxx
    from:
      backupSetPath: "polardbx-backup/polardb-x/pxcbackup-xxx"  #Remote storage path of the backup set
    time: "2023-10-20T05:57:56Z"   # Point in time for recovery
    binlogSource:
      namespace: default  # Namespace of the source instance of the log backup set to determine the path of the backup files
      storageProvider:    # Storage configuration for the log backup set
        storageName: xx
        sink: xxx

Parameter Explanation

• restore.from.backupSetPath: Remote storage path of the data backup set
• restore.storageProvider: Storage configuration used for the data backup, refer to Cluster Backup
• restore.binlogSource: Source of the log backup, including the namespace of the source instance and storage configuration

Refer to the example above to write the yaml file for recovery, and recover with the following command

kubectl apply -f pxc-pitr-restore-cross.yaml

Note:

• Recovery may fail if there is any addition or deletion of data nodes between the time of the full backup and the specified recovery point.
• Recovery may also fail if there are gaps in the incremental logs due to events like rebuilding of backup bases, which prevents continuous log generation.
• Metadata inconsistencies may occur if DDL operations are performed close to the specified recovery time point.

Suggestions:

• Conduct full backups on a regular basis.
• Trigger a full backup after any modification to data nodes.

For further operational steps, see Cluster Recovery