Replay oplog from arbitrary start time¶

Version added: 1.7.0

You can replay the oplog for a specific period on top of any backup: logical, physical, storage level snapshot (like EBS-snapshot). Starting with version 1.8.0, you can save oplog slices without the mandatory base backup snapshot. This behavior is controlled by the pitr.oplogOnly configuration parameter:

pitr:
   oplogOnly: true

By replaying these oplog slices on top of the backup snapshot with the pbm oplog-replay command, you can manually restore sharded clusters and non-sharded replica sets to a specific point in time from a backup made by any tool and not only by Percona Backup for MongoDB. Plus, you reduce time, storage space, and administration efforts on making the redundant base backup snapshot.

Warning

Use the oplog replay functionality with caution, only when you are sure about the starting time from which to replay oplog. The oplog replay does not guarantee data consistency when restoring from any backup. However, it is less error-prone for backups made with Percona Backup for MongoDB.

Oplog replay for physical backups¶

Starting with version 2.2.0, oplog replay on top of a physical backups made with Percona Backup for MongoDB is done automatically as part of point-in-time recovery.

This section describes how to manually replay oplog on top of physical backups with Percona Backup for MongoDB version 2.1.0 and earlier.

After you restored a physical backup, do the following:

Stop point-in-time recovery, if enabled, to release the lock.
Run pbm status or pbm list commands to find oplog chunks available for replay.
Run the pbm oplog-replay command and specify the --start and --end flags with the timestamps.
```
$ pbm oplog-replay --start="2022-01-02T15:00:00" --end="2022-01-03T15:00:00"
```
After the oplog replay, make a fresh backup and enable the point-in-time recovery oplog slicing.

Oplog replay for storage level snapshots¶

When making a backup, Percona Backup for MongoDB stops the point-in-time recovery. This is done to maintain data consistency after the restore.

Storage-level snapshots are saved with point-in-time recovery enabled. Thus, after the database restore from such a backup, point-in-time recovery is automatically enabled and starts oplog slicing. These new oplog slices might conflict with the existing oplogs saved during the backup. To replay the oplog in such a case, do the following after the restore:

Disable point-in-time recovery.
Delete the oplog slices that might have been created.
Re-sync the data from the storage.
Run the pbm oplog-replay command and specify the --start and --end flags with the timestamps.
```
$ pbm oplog-replay --start="2022-01-02T15:00:00" --end="2022-01-03T15:00:00"
```
After the oplog replay, make a fresh backup and enable the point-in-time recovery oplog slicing.

Known limitations¶

The oplog replay fails if you rename the entire database or a collection.

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.

Community Forum Get a Percona Expert Join Percona Squad

Last update: November 12, 2024
Created: November 12, 2024