Physical Backup and Restoration

gs_basebackup

For details, see gs_basebackup.

PITR Recovery

Background

When a database breaks down or needs to be rolled back to a previous state, the point-in-time recovery (PITR) function of MogDB can be used to restore the database to any point in time after the backup and archive data is generated.

NOTE:

• PITR can only be restored to a point in time after the physical backup data is generated.
• Only the primary node can be restored using PITR. The standby node needs to be fully built to synchronize data with the primary node.

Prerequisites

• Full data files have been physically backed up.
• WAL log files have been archived.

PITR Recovery Process

1. Replace the target database directory with the physical backup files.
2. Delete all files in the database directory pg_xlog/.
3. the archived WAL log file to the pg_xlog file. (Or you can configure restore_command in the recovery.conf file to skip this step.)
4. Create the recovery command file recovery.conf in the database directory and specify the database recovery degree.
5. Start the database.
6. Connect to the database and check whether the database is recovered to the expected status.
7. If the expected status is reached, run the pg_xlog_replay_resume() command so that the primary node can provide services externally.

Configuring the recovery.conf File

Archive Recovery Configuration

• restore_command = string

  The shell command is used to obtain the archived WAL files among the WAL file series. Any %f in the string is replaced by the name of the file to retrieve from the archive, and any %p is replaced by the path name to it to on the server. Any %r is replaced by the name of the file containing the last valid restart point.

  For example:

  restore_command = 'cp /mnt/server/archivedir/%f %p'

• archive_cleanup_command = string

  This option parameter declares a shell command that is executed each time the system is restarted. archive_cleanup_command provides a mechanism for deleting unnecessary archived WAL files from the standby database. Any %r is replaced by the name of the file containing the last valid restart point. That is the earliest file that must be kept to allow recovery to be restartable, so all files older than %r can be safely removed.

  For example:

  archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

  If multiple standby servers need to be recovered from the same archive path, ensure that WAL files are not deleted from any standby server before the recovery.

• recovery_end_command = string

  This parameter is optional and is used to declare a shell command that is executed only when the recovery is complete. recovery_end_command provides a cleanup mechanism for future replication and recovery.

Recovery Object Configuration

• recovery_target_name = string

  This parameter declares that the name is recovered to a recovery point created using pg_create_restore_point().

  For example:

  recovery_target_name = 'restore_point_1'

• recovery_target_time = timestamp

  This parameter declares that the name is recovered to a specified timestamp.

  For example:

  recovery_target_time = '2020-01-01 12:00:00'

• recovery_target_xid = string

  This parameter declares that the name is recovered to a transaction ID.

  For example:

  recovery_target_xid = '3000'

• recovery_target_lsn = string

  This parameter declares that the name is recovered to the LSN specified by log.

  For example:

  recovery_target_lsn = '0/0FFFFFF'

• recovery_target_inclusive = boolean

  This parameter declares whether to stop the recovery after the recovery target is specified (true) or before the recovery target is specified (false). This declaration supports only the recovery targets recovery_target_time, recovery_target_xid, and recovery_target_lsn.

  For example:

  recovery_target_inclusive = true

NOTE:

• Only one of the four configuration items recovery_target_name, recovery_target_time, recovery_target_xid, and recovery_target_lsn can be used at a time.
• If no recovery targets are configured or the configured target does not exist, data is recovered to the latest WAL log point by default.

gs_probackup

For details, see gs_probackup.