New answers tagged mongodb
0
You currently have a member running in secondary, because it cannot form a majority. This is why you should always have an odd number of nodes in a replica set (one can be an arbiter) and I would recommend adding a third node as soon as possible once you get things back to normal.
In terms of how to get the second node up and running, do the following:
...
1
The general recommendation is to have all members of a cluster or replica set running the same version, inclusing arbiters. Hence, generally you should upgrade arbiters when you upgrade everything else. In fact I would say to upgrade them first since if you have things configured correctly there will be no interruption in terms of operations from an ...
1
"Is this realistic to do with something like MongoDB?"
If "realistic" means can be engineered to produce acceptable performance then the answer depends on whether you will do with appropriate benchmarking before putting it into production. You can replace "MongoDB" in your question with anything from Access to Oracle and the answer remains basically the ...
0
Note While not recommended, the minimum supported configuration for replica sets includes one primary, one secondary, and one arbiter. The arbiter requires fewer resources and lowers costs but sacrifices operational flexibility and redundancy.
from http://docs.mongodb.org/manual/core/replica-set-architectures/
you don't have enough members to maintain ...
0
Why do you have Score model?
Why not keep only User and Match models and for each have a score attribute?
In this schema you have only the updates per score.
If its due to redundancy of attributes, please note this is common in a document based schema design.
0
Just to answer my question, in case people come across it:
1) Yes, it is possible for A, and C to be committed and B to fail. Atomicity only exists on documents in MongoDB.
2) Yes, this is possible as well.
See more for reading here:
http://docs.mongodb.org/manual/tutorial/isolate-sequence-of-operations/
3
In general, no they are not distributed in order. However, there is a way that this (or at least approximately this) distribution can occur during normal operations. To explain:
If you have all of your data on a single shard (a-z) and then add a second shard, the balancer will redistribute the data to the new shard by migrating chunks.
The way the ...
3
There are a number of reasons not to use MongoDB as a pure key-value store, and there are some reasons to consider it. Mongo is optimized as a document store - it indexes all the fields in a document, and has rich primitives for JSON objects and hierarchies. You can use it as a key-value store, but the single-threaded nature means you won't be getting good ...
1
In general, yes, you can do this, the 2.4 binaries can be used as drop in replacements. However, there are exceptions. In sharded clusters for example, you have to make sure to do the meta data upgrade
Essentially, the caveats are all really deployment and feature (authentication), not version based. Basically make sure to read the notes here:
...
1
The short answer is, at least for the user you list: this is how it is supposed to work with the new user privilege model in 2.4+
To explain:
The userAdminAnyDatabase role means that the user you have now created will be able to grant access (for itself, or any other users) to any other database, hence the designation in the docs as a "super user". ...
Top 50 recent answers are included
