several questions about mongo durability and sharding
cheetah
Scott Hernandez
> Hi guys,
>
> I have several questions about mongo's durability and sharding:
> 1. If a client writes a document with a write concern {fsync:true}, will
> this document update be seen by other clients immediately after the changes
> are applied in memory or after the files are synced into disks?
It is synchronous but memory is king. Remember, all the files are
memory mapped, and flush in the background by the OS.
> 2. I read some documents about mongos caching the data from the config
> server. I am wondering how this cache is managed? Is the mongos caching all
> the chunk information or just chunks it accessed?
Yes. Each shard also has the chunk information for the chunks they own
and they can cause the mongos to invalidate their cache based on a
special shardVersion handshake, and response for shard-aware
connections.
> 3. Who decides sharding and balancing of chunks? Mongos or config server?
> When allocating/rebalancing chunks, what parameters are contributed to the
> decision (disk size of a shrad, I/O speed of a shard, etc)?
The config server just hold data, nothing more.
> 4. When sharding is used, will namespace files also sharded so that the
> number of collections in a database can be increased? If not, the namespace
> files will be replicated on every shard?
All shards just hold data and act normally as any mongod; they can
even be used directly without going through mongos.
Replicating namespaces doesn't make any sense when there is no need.
Namespaces are local to a shard since it represents what is stored
there.
> Brief reply or a point to some reference are highly appreciated. Thanks very
> much for the help.
Please let us know if found places in the docs which were not clear on
these points or if there are places which need more documentation.
> Regards,
> Wen
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.
cheetah
On Thu, Jan 26, 2012 at 11:16 PM, cheetah <xuw...@gmail.com> wrote:It is synchronous but memory is king. Remember, all the files are
> Hi guys,
>
> I have several questions about mongo's durability and sharding:
> 1. If a client writes a document with a write concern {fsync:true}, will
> this document update be seen by other clients immediately after the changes
> are applied in memory or after the files are synced into disks?
memory mapped, and flush in the background by the OS.
Yes. Each shard also has the chunk information for the chunks they own
> 2. I read some documents about mongos caching the data from the config
> server. I am wondering how this cache is managed? Is the mongos caching all
> the chunk information or just chunks it accessed?
and they can cause the mongos to invalidate their cache based on a
special shardVersion handshake, and response for shard-aware
connections.
The config server just hold data, nothing more.
> 3. Who decides sharding and balancing of chunks? Mongos or config server?
> When allocating/rebalancing chunks, what parameters are contributed to the
> decision (disk size of a shrad, I/O speed of a shard, etc)?
Scott Hernandez
> Hi Scott,
>
> Thanks a lot for the reply. My reply is inline.
>
> On Thu, Jan 26, 2012 at 8:29 PM, Scott Hernandez <scotthe...@gmail.com>
> wrote:
>>
>> On Thu, Jan 26, 2012 at 11:16 PM, cheetah <xuw...@gmail.com> wrote:
>> > Hi guys,
>> >
>> > I have several questions about mongo's durability and sharding:
>> > 1. If a client writes a document with a write concern {fsync:true}, will
>> > this document update be seen by other clients immediately after the
>> > changes
>> > are applied in memory or after the files are synced into disks?
>>
>> It is synchronous but memory is king. Remember, all the files are
>> memory mapped, and flush in the background by the OS.
>
>
> I know this write operation will be synchronous. But I am wondering will
> this write block other clients' read on this document until this document is
> written to the disk (fsync)?
There are two separate operations. 1) the write, 2) checking the state
of the write.
1.) Is the same no matter what and has to do with how the
reader-writer lock works.
2.) It depends on the options. It will only affect that single
operation to block for the criteria requires.
>
> AFAIK, the write will do the following steps: 1) apply changes in memory, 2)
> write to journal, 3) fsync to disk (every 1 minute or so?). Suppose the
> write has already written to the journal, but not to the disk yet, this
> write is still blocked. But when the other clients try to read this
> document, will they get new value from memory or they get blocked, or they
> get the old value?
There are no transactions or read isolation where reads will come from
one state of the docs when a write is happening to another. Mongodb
does in-place updates so there is only one instance of the
authoritative doc at a time. During the write, no one else can read or
touch that document until the document write is finished -- it is an
atomic operation.
See above for how journal/fsync work.
>>
>> > 2. I read some documents about mongos caching the data from the config
>> > server. I am wondering how this cache is managed? Is the mongos caching
>> > all
>> > the chunk information or just chunks it accessed?
>>
>> Yes. Each shard also has the chunk information for the chunks they own
>> and they can cause the mongos to invalidate their cache based on a
>> special shardVersion handshake, and response for shard-aware
>> connections.
>>
>> > 3. Who decides sharding and balancing of chunks? Mongos or config
>> > server?
>> > When allocating/rebalancing chunks, what parameters are contributed to
>> > the
>> > decision (disk size of a shrad, I/O speed of a shard, etc)?
>>
>> The config server just hold data, nothing more.
>
> http://www.mongodb.org/display/DOCS/Sharding+Administration#ShardingAdministration-Balancing
> The doc shows the balancer is doing the job. So it is part of Mongos? Does
> the auto-balancer consider only evenly chunk distribution or some other
> factors? For example, if a shard has a larger disks, will the balancer move
> more trunks to this shard?
The balancer is part of mongos and moves from instance to instance
periodically based on a distributed lock kept in the config database.
The balancer initiates migrations on the shards but doesn't actually
touch/see the data. Balancing just keeps the number of chunks even
(within 8) on all shards. There is a limiting option as a suggestion
for how much space to use on each shard.
http://www.mongodb.org/display/DOCS/Configuring+Sharding#ConfiguringSharding-OptionalParameters