[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 ] |
|
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, |
| 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.
|
| Comment by Edwin Zhou [ 05/Nov/20 ] |
|
Further investigation leads me to believe that your improvement duplicates 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 ] |
|
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:
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 |