Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 3.4.19, 3.6.11, 4.0.6, 4.1.7
Affects Version/s: None
Component/s: Replication
Labels:
- neweng

Backwards Compatibility:
Fully Compatible
Backport Requested:

v4.0, v3.6, v3.4
Sprint:
Repl 2018-11-05, Repl 2018-11-19, Repl 2018-12-03, Repl 2018-12-17
Case:
Confidence Status:
None
Work Order:
3
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

As a sanity check in case a user manually modifies their local database in a way that puts them into this state

is related to

SERVER-38366 Replica set nodes update the term without verifying the config version can lead to unnecessary stepdown.

Closed

SERVER-38504 On Primary, to verify that our lastAppliedOpTime is lagged behind the TopologyCoordinator::_lastCommittedOpTime, we should compare both its term and timestamp for pv1.

Closed

SERVER-38505 For pv1, to determine if the oplog entries are applied out of order, we should compare both the term and timestamp of firstOpTimeInBatch and lastAppliedOpTimeAtStartOfBatch

Closed

Assignee:: Suganthi Mani
Reporter:: Spencer Brody (Inactive)
Participants:: Githook User, Gregory McKeon, Spencer Brody, Suganthi Mani
Votes:: 2 Vote for this issue
Watchers:: 9 Start watching this issue

Created:: Jun 14 2018 10:06:35 PM UTC
Updated:: Oct 29 2023 10:30:46 PM UTC
Resolved:: Dec 11 2018 05:11:08 PM UTC
Confidence Status Last Update:: 30/Oct/18 4:33 AM

Details

Description

Attachments

Issue Links

Forms

Activity

People

Dates