[SERVER-62633] Implement the first phase of the restore algorithm where the oplog is replayed on restored collections Created: 13/Jan/22  Updated: 06/Dec/22  Resolved: 24/Jan/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-62627 Implement the first phase of the rest... Closed
depends on SERVER-62630 Implement the first phase of the rest... Closed
is depended on by SERVER-62631 Implement the abort logic during a fa... Closed
is depended on by SERVER-62634 Implement the final steps of the firs... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

These are the next steps after SERVER-62630.

If a timestamp was specified for a point-in-time restore, the oplog entries in local.oplog.restore will be replayed on the restored collections using the applyOps command.

  • Oplog entries for collections not restored will be skipped.
  • Oplog entries referencing a database namespace that was renamed will have to be re-written with the new database namespace before being applied.
  • An applyOps oplog entry can contain multiple oplog entries referencing multiple collections. This is how committed multi-document transactions are structured. These applyOps oplog entries will have to be re-written to remove the oplog entries referencing collections not restored before being applied.

Generated at Thu Feb 08 05:55:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.