[SERVER-38731] Ability to specify sync source read preference in initial sync Created: 20/Dec/18  Updated: 29/Oct/23  Resolved: 18/Mar/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.4.0-rc0, 4.2.7, 4.7.0

Type: Improvement Priority: Major - P3
Reporter: Arnie Listhaus Assignee: Matthew Russotto
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Documented
is documented by DOCS-13526 Investigate changes in SERVER-38731: ... Closed
Related
related to SERVER-31487 Replace replSetSyncFrom resync option... Closed
related to SERVER-44272 Resync data on replSetSyncFrom during... Closed
is related to SERVER-47056 Do not use readOnce cursors for colle... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4, v4.2
Sprint: Repl 2020-03-09, Repl 2020-03-23
Participants:
Case:

 Description   

Our current implementation of choosing a sync source for initial sync as well as steady state sync could be improved to include preferences provided by the user for situations including:

  • not wanting to sync from the primary to mitigate impact to production applications that are targeting the primary
  • preference to sync from a node on the same LAN vs having multiple nodes make the trip across the WAN (even if ping times would dictate otherwise)
  • syncing from a specific node based on specific user preference

If the preference is not specified or can not be accommodated then we should fall back to choosing based on latency and currency as we do today.  

It would be helpful for the specification of a sync source preference to be part of the replica set configuration so it is easily noticed and easily managed.  The log should reflect the preference and the reason it was overridden when need be.



 Comments   
Comment by Githook User [ 21/Apr/20 ]

Author:

{'name': 'Matthew Russotto', 'email': 'matthew.russotto@10gen.com', 'username': 'mtrussotto'}

Message: SERVER-38731 Implement ability to specify sync source read preference in initial sync
Branch: v4.2
https://github.com/mongodb/mongo/commit/5988fe51d7a18c022b51eda6f7243123b4e9a6ab

Comment by Githook User [ 27/Mar/20 ]

Author:

{'name': 'Matthew Russotto', 'username': 'mtrussotto', 'email': 'matthew.russotto@10gen.com'}

Message: SERVER-38731 Implement ability to specify sync source read preference in initial sync

(cherry-picked from commit 7296a460f826c8a618147e09606c5f1935c482a4)
Branch: v4.4
https://github.com/mongodb/mongo/commit/38cbeab8b2033274fdbbcf692a8c8a4f69febd4f

Comment by Judah Schvimer [ 27/Mar/20 ]

When backporting to 4.2 we should make the default read preference always 'nearest' to not have a minor version behavior change.

Comment by Githook User [ 18/Mar/20 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-38731 Implement ability to specify sync source read preference in initial sync
Branch: master
https://github.com/mongodb/mongo/commit/7296a460f826c8a618147e09606c5f1935c482a4

Comment by Judah Schvimer [ 24/Feb/20 ]

Agreed upon behavior:

  • We will add a new startup parameter, ‘initialSyncSourceReadPreference’, which when present, must be a string equal to one of the acceptable read preference modes.
    • Note, if the user specifies ‘readPreference: primary’ and there is no primary, they will not be able to initial sync. Presumably this is the behavior they desire.
    • This will not support the use of tags or ‘maxStalenessSeconds’ in the read preference.
  • Default for re-syncing nodes (initial syncing nodes with ‘votes: 1’) is ‘primaryPreferred’
  • Default for newly added nodes (initial syncing nodes with ‘votes: 0’) is ‘nearest’
  • This parameter will take precedence over ‘chainingAllowed: false’ when explicitly present, though the defaults will not take precedence over ‘chainingAllowed: false’.
  • We will use heartbeat information to choose a sync source based on read preference.
    • ‘nearest’ will essentially work as today.
    • ‘primary’ will essentially work as ‘chainingAllowed: false’ today.
Generated at Thu Feb 08 04:49:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.