[SERVER-10773] Provide mechanism for cloud to reliably replay an oplog into a secondary, including restart Created: 15/Sep/13  Updated: 06/Dec/22  Resolved: 09/Jan/18

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

Type: Improvement Priority: Major - P3
Reporter: Cailin Nelson Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: brs
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-12508 Add Replica Set Restore Mode (for poi... Closed
Related
is related to TOOLS-176 Dump/Restore with --oplog not point-i... Closed
is related to TOOLS-852 mongorestore --noDataRestore Accepted
is related to SERVER-19618 Allow applyOps to ignore unique index... Closed
Assigned Teams:
Replication
Participants:

 Description   

Provide a new option that can be invoked as a startup option, or be set as a global option later that tells the server to ignore all secondary index unique constraints.



 Comments   
Comment by David Dana [ 09/Jan/18 ]

Backup Backlog Grooming Note

  • We haven't seen this pop up in awhile. The real concern is SERVER-12508 which we will keep an eye on.
Comment by Scott Hernandez (Inactive) [ 15/Mar/16 ]

This is basically a duplicate of SERVER-12508 – which is a mechanism to push oplog segments to restore from a backup in a consistent way (by tools).

Comment by Andy Schwerin [ 15/Sep/13 ]

IIRC, the server can only do what it does because it identifies the beginning and ending of write-batches, in between which other writes and reads cannot occur, plus when replaying after an initial sync, again when other reads and writes are forbidden. Putting the server into such a mode at start-up implies that it would never allow other reads and writes, would have to trust the the authorized writer to make the system consistent. It's a somewhat risky approach, from our side of the table, since it constrains the kinds of changes we can make to the synchronization and replication systems. Who is this for, exactly?

Comment by Cailin Nelson [ 15/Sep/13 ]

We would like to be able to mimic what the core server does when it replays oplogs. Thus, I believe we want the latter: add the duplicate key and pretend the index is not unique.

Comment by Eric Milkie [ 15/Sep/13 ]

What do you want the new behavior to be if a unique index violation occurs when updating an index? We can either keep the index unique and silently skip adding the duplicate key, or we can add the duplicate key and pretend the index is not unique.

Generated at Thu Feb 08 03:24:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.