Skip to content
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

make dashboard readPreference from secondary #435

Closed
drorsun opened this issue Jun 26, 2016 · 3 comments
Closed

make dashboard readPreference from secondary #435

drorsun opened this issue Jun 26, 2016 · 3 comments

Comments

@drorsun
Copy link

drorsun commented Jun 26, 2016

I would like to be able to configure parse-dashboard to prefer secondary replica-set members in mongo db when scanning for data. I understand this involves integration with the parse-server which is actually holding the connections and doing the queries, but is that somehow possible today?

If not please consider this a feature request.

@johanarnor
Copy link

johanarnor commented Aug 24, 2018

@drorsun @flovilmart Any specific reason this was closed? I guess it's possible now, since parse-community/parse-server#3865 is merged? I can take a stab at a PR, if someone guides me in the right direction.

It would really help with #612 as well.

@flovilmart
Copy link
Contributor

Closed due to inactivity and lack of interest.

I don’t know what the right direction is for this one.

Also it’s pretty much unrelated to the issues hou’re describing.

You’ll be trashing the secondary, which in turn will increase the replication lag, which in turn will trash the primary.

Possible solutions:

  1. A dedicated server instance for your dashboard that writes all requests with secondary; and not the main one.
  2. Properly index your data
  3. Configure correctly the maxMs for mongo, so your queries don’t run indefinitely

@johanarnor
Copy link

johanarnor commented Aug 24, 2018

First, sorry I didn't see that the PR was closed 2 years after opening. Just saw 26 Jun 2016 -> closed on 26 Jun and assumed it was the same year.

Hm, didn't know that thrashing the secondary would severely impact the primary.

Regarding the solutions:

  1. Is it possible to write to the secondary DB as well? I assumed that one could only write to primary in order to not make the DBs out of sync.
  2. It's quite wasteful to index every single "column", especially if we need 'createdAt' in the index as well.
  3. Will take a look at the maxMs, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants