4 ms·
Interesting feedback ... I agree on the log messages that look terrifying yet, when googled, are like "oh, that's normal, don't worry about that." I also agree
by jasonmccay 14y ago
Interesting feedback ... I agree on the log messages that look terrifying yet, when googled, are like "oh, that's normal, don't worry about that." I also agree that the 2.x versions of MongoDB have been a great step forward for stability and performance.
On the logging, not sure what you mean by the old logs get clobbered. Is this, perhaps, some house-cleaning job that you have on your server? When we stop/start processes, the logs are appended and keep going.
On the issues with primary/secondary and state changes, do you host your databases on Amazon? We have often found that when we have this issue, it was pinpointed back to some temporary intra-zone networking glitch with AWS ... either with their name resolution or a blip in one zone being unable to see another zone in the window of time that MongoDB has set for the response.
These often (if not all the time) go unreported by AWS until you get them to dig a bit and report back. We effectively utilize priority to keep the member we want as primary and if a state change does occur, it moves back once the full set is healthy again.
- mediocregopher 14y ago>On the logging, not sure what you mean by the old logs get clobbered. For us the logs are not opened in append-mode, just write. We don't do any house cleaning except for logrotate, but that only runs nightly and isn't the cause of what we're seeing. Like I said, it may not be for the normal mongod instance, but it's definitely true for mongos. I'll double-check on the version number of what we're running > do you host your databases on Amazon? Nope, all owned servers, over a local network on a switch we own as well. The switching happens on some clusters more then others, so it's possibly a usage related thing.