Skip to content

feat(query): set read preference to SECONDARY by default #1466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

omairvaiyani
Copy link

Use-case

We think it makes sense to keep the load off the primary where possible, but here is one scenario that has stung us many times:

Given how flexible the data-browser is, it's very easy to accidentally set the sort on a large collection on an unindexed field. Whilst there are multiple lines of defences that we can add (beforeFind in parse-server, no unindexed queries in MongoDB, etc), we think this is a good starting point for other developers.

Implementation
Right now, I've just set the common find and count queries to be SECONDARY. None of the critical flows such as writes, or even reads on Roles, ACLs etc are set to use this preference. For now, I've not added a configuration option to disable this. Happy to look into this if it's helpful?

@davimacedo
Copy link
Member

It makes a lot of sense for me but I believe it should be an option that the developer should opt-in maybe per app. I'd also set it to SECONDARY_PREFERRED (and not SECONDARY) for the case the database is not running on a replica set or for any reason the secondary is out.

@stale
Copy link

stale bot commented Mar 27, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state:wont-fix Won’t be fixed with a clearly stated reason label Mar 27, 2020
@stale stale bot closed this Apr 3, 2020
@mtrezza
Copy link
Member

mtrezza commented May 8, 2020

This is a very delicate topic. The default read preference of Parse Server should be what the default of the database is, which is PRIMARY. I am not aware of a database cluster that would not make PRIMARY the default, because anything else is a special mode that requires many considerations regarding availability, data consistency, etc. and usually additional settings for the cluster itself to get the desired outcome. Setting it to anything else than PRIMARY requires a firm understanding of the implications, otherwise one may face issues that are hard to debug.

Given how flexible the data-browser is, it's very easy to accidentally set the sort on a large collection on an unindexed field.

That I fully agree with, the solution might be as simple as this: #1497. A collection scan that brings the primary down would also be problematic when read from the secondary, because it increases the replication lag and secondary reads would show a high level of data inconsistency. A collscan should be avoided regardless of the node type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state:wont-fix Won’t be fixed with a clearly stated reason
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants