[SERVER-31384] applyOps should propagate oplog application mode Created: 04/Oct/17  Updated: 30/Oct/23  Resolved: 15/Nov/17

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-31387 oplog application conflates upserting... Closed
Related
related to SERVER-31019 Changing fCV during initial sync lead... Closed
related to SERVER-31507 Add option to applyOps to fail on upg... Closed
related to SERVER-31189 fassert if feature compatibility vers... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Sprint: Repl 2017-11-13, Repl 2017-12-04
Participants:

 Description   

When an applyOps oplog entry is applied, it always sets the "inSteadyStateReplication" flag to true for commands and to the "alwaysUpsert" value for operations.

This means that an applyOps command with a renameCollection command in it will not cause initial sync to restart.

We should pass the appropriate OplogApplication::Mode into the applyOps function.



 Comments   
Comment by Githook User [ 15/Nov/17 ]

Author:

{'name': 'William Schultz', 'username': 'will62794', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-31384 applyOps should correctly propagate oplog application mode

(cherry picked from commit d5cce0599a6f44f653eca53d728bb52b2f8fae6c)
Branch: v3.6
https://github.com/mongodb/mongo/commit/542489784c16b449b13370cd0b39fa04034f6649

Comment by Githook User [ 15/Nov/17 ]

Author:

{'name': 'William Schultz', 'username': 'will62794', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-31384 applyOps should correctly propagate oplog application mode
Branch: master
https://github.com/mongodb/mongo/commit/d5cce0599a6f44f653eca53d728bb52b2f8fae6c

Generated at Thu Feb 08 04:26:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.