

Notes on MongoDB, GridFS, sharding and deploying in the cloud - mvip
http://viktorpetersson.com/2012/01/29/notes-on-mongodb-gridfs-and-sharding-in-the-cloud/

======
mvip
Also, if you're curious about bandwidth limitations in this particular cloud,
take a look at these benchmarks:
[http://viktorpetersson.com/2012/01/23/benchmarking-
virtual-n...](http://viktorpetersson.com/2012/01/23/benchmarking-virtual-
network-drivers-under-freebsd-9/)
[http://viktorpetersson.com/2012/01/24/benchmarking-and-
tunin...](http://viktorpetersson.com/2012/01/24/benchmarking-and-tuning-
freebsds-virtio-network-driver/) (Using CloudSigma as the cloud-vendor and
FreeBSD 9 as the host)

------
nknight
I might be missing something due lack of experience with MongoDB, but what did
disk I/O have to do with the secondaries falling behind, and why did
effectively eliminating one of the secondaries "fix" that? The description
makes me think there's a pathological case lurking in MongoDB that needs to be
looked at more closely.

~~~
mvip
The reason why the secondaries were falling behind was because the I/O was
maxed out on the primary. It was barely able to keep up with the regular load,
and hence reducing the load (by only having one node replicating instead of
two) reduce the I/O load significantly.

That said, reducing the number of secondaries was just a short-term solution.
The long-term solution is to convert to a sharded environment and offload the
one maxed out node.

~~~
nosequel
Wouldn't the proper behavior be to provide some sort of back pressure so that
it cannot decide for you to no longer backup your data to the replica set?

I would expect that if you say you want data replicated, that if it can't
handle that under load, it would back off on the load that it is capable of
instead of going the pathological route of simply not backing up. If under
load the primary goes down with a serious disk failure, you now just lost a
ton of data that you expected were being backed up all along.

~~~
nknight
You can apparently invoke a level of synchronous behavior in MongoDB with the
getLastError command:
<http://www.mongodb.org/display/DOCS/getLastError+Command>

Conceptually, its abilities look a lot like Cassandra's "configurable
consistency" model.

~~~
jbellis
Consistency and durability are two different things.

