[DOCS-15441] Investigate changes in REP-784: PrimaryPreferred read preference on the destination can lead to regressing state Created: 23/Jun/22  Updated: 22/Jan/24

Status: Backlog
Project: Documentation
Component/s: C2C, manual, Server
Affects Version/s: None
Fix Version/s: 1.0.0

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: backlog, request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
Participants:
Days since reply: 1 year, 32 weeks, 6 days ago
Epic Link: DOCSP-22764

 Description   
Original Downstream Change Summary

We modified the way we handle read preference in mongosync:

  • On the source, we respect whatever the user requested and use PrimaryPreferred if they did not set any preference.
  • On the destination, we overwrite whatever the user requested with Primary.

If the user reverses the replication direction, we will apply the same logic on the new source and new destination.

e.g.

  • User asks for nearest on source and secondaryPreferred on destination.
  • We will use nearest on source (as requested) and Primary on destination (overwritten).
  • If they call Reverse, we will use secondaryPreferred on the new source (as requested) and Primary on new destination (overwritten).

    Description of Linked Ticket

    The following scenario is possible:
    1. a. Replicator persists state on destination as COMMITTING
    1. b. State COMMITTING is saved on majority of nodes, but not some secondary S, which still thinks the state is RUNNING.
    2. Replicator is killed.
    3. Replicator restarts, and tries to restore its resume data. Since it uses PrimaryPreferred, if the primary is unavailable the replicator may read from S, and restore its state as RUNNING.

We may also see similar issues whenever we hit the api/v1/progress endpoint: it may return stale data.

To solve this, we should:
1. Force destination readPreference to be primary
2. Recreate mongo clients on reverse (since the destination should have the readPreference set)

Moved part on linearizability to https://jira.mongodb.org/browse/REP-854


Generated at Thu Feb 08 08:12:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.