[SERVER-52536] Mongos to provide read from secondary shard nodes Created: 02/Nov/20  Updated: 17/Nov/22

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: 4.2.8
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Aayushi Mangal Assignee: Salman Baset
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

If mongos could have any parameter like read only from secondary shard nodes.

We could use secondary preferred or secondary read preferences, but in that case any user might not use this preference and able to directly read from Primary and if one need to restrict that mongos complrity from reading primary, not found any.

To stop this we have to create a mirror cluster that will sync delta, for that we can use mongo-connector or mongo-shake third party tools.

But these also come with challenges like: Index sync is not possible. 

Here is community discussion I had: https://developer.mongodb.com/community/forums/t/mongo-connector/8062

It would be great feature if mongos could be restricted at that level to read from primary.

 

 



 Comments   
Comment by Edwin Zhou [ 10/Nov/20 ]

Hi aayushi.mangal3@gmail.com,

Thanks for providing answers to my questions, it really helps clarify your use case and requirements! This feature doesn't currently exist but I can assign this ticket to the appropriate team to be evaluated against our currently planned work. Updates will be posted on this ticket as they happen.

Kind regards,
Edwin

Comment by Aayushi Mangal [ 07/Nov/20 ]

Hi Edwin,

Thank you so much for the details.

Do you agree that the ticket addresses the feature you're looking to add?

Partially yes, but if we could do one mongos dedicated to users (with the parameter read from secondary) to that particular mongos node only. so any user can connect from that can read only from secondary, is that feasible.

Would you be open to a feature that allows modifying read preference as a user role/privilege? That way we can specify read preference at the user level and ensure that we're reading from the secondary.

Yes, this sounds good. If a user with read pref role, that will also help.

  • is that user and read pref work for shard cluster reading from mongos?
  • is that feature already available, if yes please redirect me to that document.
  • if no, what will be the ETA to have this feature in use.
Comment by Edwin Zhou [ 05/Nov/20 ]

Hi aayushi.mangal3@gmail.com,

Further investigation leads me to believe that your improvement duplicates SERVER-17355, a feature request that allows mongos to override a client's readPreference. The motive of the feature request was to enforce read only on a router so specific clients accessing the router, e.g. DBAs, wouldn't need to set read preference to ensure reads from the secondary node. We were unable to justify allowing mongos to override the client's read preference as other applications accessing the mongos may need to access data with a differing read preference. Additionally, as there is no way to enforce the relationship between config server and connection string, config drift becomes a risk.

Do you agree that the ticket addresses the feature you're looking to add?

Would you be open to a feature that allows modifying read preference as a user role/privilege? That way we can specify read preference at the user level and ensure that we're reading from the secondary.

Best,

Edwin

Comment by Aayushi Mangal [ 04/Nov/20 ]

Hello Edwin,

Thank you for quick response, please find my case below:

Similar to a replica set, where we can set readPreference to secondary to restrict reads to only secondaries, you'd like a parameter in the mongos that enforces reads on secondary shard nodes:

Yes, in mongos, for example:

We have multiple mongoses running. And one mongos is being used only for read purpose.  We can set any parameter to mongos level itself, that will force user to read from secondary (the reads will automatic route to all the secondaries of shards. )

This is because, in case we can define readpref from user end, but from mongos, if we can be able to eliminate that mistake, like any user is reading from primary by mistake of not using read pref mode, any parameter if already exist to control from DBA side for strict read preference for secondary.

Alternatively at present we have to use mongo-connector or mongoshake kind of tool, that sync kind of mirror our whole cluster with real time data, from where we have to give access to those users where we do not want them to host from our primary shards.

Again these tool comes with huge maintenance and challenges. so any utility like this will be helpful.

Any other suggestions are most welcome to this problem.

 

Comment by Edwin Zhou [ 04/Nov/20 ]

Hi aayushi.mangal3@gmail.com,

Thank you for your improvement submission! I'd like to clarify the functionality and use case of this improvement.

Similar to a replica set, where we can set readPreference to secondary to restrict reads to only secondaries, you'd like a parameter in the mongos that enforces reads on secondary shard nodes.

I'd love some additional clarification to the following statement:

but in that case any user might not use this preference and able to directly read from Primary and if one need to restrict that mongos complrity from reading primary, not found any.

Are you indicating that setting readPreference to secondary or secondaryPreferred does not completely restrict users from reading the primary node? Could setting readPref on the application level potentially solve that for you?

Could you provide an example use case for this improvement so I can have a better understanding of its benefits?

Best,

Edwin

Generated at Thu Feb 08 05:28:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.