[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: |
|
||||||||||||||||||||||||
| 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
|
| Comment by Scott Hernandez (Inactive) [ 15/Mar/16 ] |
|
This is basically a duplicate of |
| 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. |