Stuck in Moped::Errors::ConnectionFailure: Could not connect to a primary node for replica set #348
Comments
|
How do you go about tuning those? How do you know what to set them to? Are there guidelines? |
|
In general, you should have a pool_size that is equal to or greater than the number threads you are running. You shouldn't need to tune pool_timeout. Here is an update submitted to mongoid for generating the mongoid.yml giving more details on those configs https://github.com/mongoid/mongoid/pull/3883/files |
|
These PRs might also be useful to you, in adding more/better logging in error situations and giving metrics on per request in rails: https://github.com/mongoid/mongoid/pull/3885 |
|
#352 has so far been good to us in production (72 hours). So it has improved things I want to say. |
|
I'm seeing this error as well. |
|
+1. We see this a couple of times per day, seemingly on a random basis. |
|
+1 also seeing this. |
|
I think, MOPED also use wrong thread-safe code. |
|
Interesting. Does anyone see this behavior with unicorn? I've seen it with puma (threads), but don't have anything in production with unicorn. Wondering if switching the app server to unicorn might be an easy "fix", because it seems like the real fix could take a bit of time. |
|
@arthurnn any thoughts on this issue? |
|
I'm using sidekiq gem and I have not choice. |
|
I just spent 20 minutes debugging an issue with this error message, and I found that when calling .find(nil) in moped it results in this (incorrect) error message. Whereas without arguments it's ok: Expected error message would be something along InvalidFind |
|
+1 |
|
who still having this problem and can help me with the setup environment and a description on how to reproduce it? |
|
+1 @wandenberg , we still have this problem in production. It is simple to reproduce it, shutdown one of the server in the replication or close the port. |
|
+1. Monkey increasing POOL_SIZE seems to give more time between errors. |
|
+1 |
1 similar comment
|
👍 |
|
We're seeing this error crop up in some sidekiq jobs. |
|
+1, still see the issue Moped::Errors::ConnectionFailure traceback |
|
How do you properly set up a moped pool if not using mongoid? Here is how I'm doing it, and still occasionally getting these errors: $mongo_pool = ConnectionPool.new(size: 30, timeout: 3000) do
mongo_client = Moped::Session.new(Moped::Uri.new(uri_string).hosts)
mongo_client.use(dbname)
end
# have one main one open
mongo_client = Moped::Session.new(Moped::Uri.new(uri_string).hosts)
$mongo = mongo_client.use(dbname)where uri_string is in the format: mongodb://1.2.3.4:27017/desired_db_name Might end up just dropping moped as I'm not even using mongoid and that seems to be the biggest use/support case :/ |
|
It could be that mongo is not running. Have you tried: |
|
@elenatanasoiu the problem is that mongod is running and replica set is healthy but these error messages crop up nevertheless |
|
Hey, did you find any solution ? |
|
@bastoune we used sidekiq for background jobs and puma. Both being multithreaded, supporting 25 and 16 threads by default. Fixed it by tuning poolsize, sidekiq + puma threads. |
|
@shivamv Thanks for the reply, going to spend more time to understands this ;) |
|
@shivamv thanks, it help full, maybe somebody miss turn on docker have mongoid inside? |
and others
Occasionally we see a machine or two stuck in this. I am not sure when this happens, but about 10% of nodes end up in this state every 24 hours. The MongoDB cluster is doing fine.
This issue could probably use more detail, please tell me what to look for next time I have a machine in this state.
The text was updated successfully, but these errors were encountered: