What would happen if different elements of mongo cluster would become unavailable

[Дмитрий Максименко]

Hello.

Let's imagine we have a situation where a read\write operations with mongo occurs.

What will happen if mongos or configuration sever or primary server or secondary go down?

I mean if read operation occurs and configuration sever goes down. Would read operation continue?

Thanks

[markh]

Hi,

Regarding the mongos question, the operation will fail. When the mongos restarts, if the driver successfully catches the exception, it will restart.

If any of the config servers goes down, the cluster's meta-data goes read only. Despite such a failure, the MongoDB cluster can still be read from and written to.

Thanks

Mark

[Дмитрий]

Thanks for your reply. 

What does meta-data mean which would read only? 

Is read/write process interrupts if conf server goes down? 

07.08.2012, в 18:10, markh <ma...@10gen.com> написал(а):

--
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
See also the IRC channel -- freenode.net#mongodb

[markh]

Hi,

No worries. Please find my answers below - 

>> What does meta-data mean which would read only? 

This means that no splits or migrates can happen.

>> Is read/write process interrupts if conf server goes down? 

No

I would strongly encourage you to read the sharding documentation here.

Thanks

Mark

mongodb-user+unsubscribe@googlegroups.com

[Дмитрий Максименко]

Thanks Mark!

I've got another question. How can user would know that the data he has just written on a primary server wasn't replicated on a secondary and a primary went down?

He waits for the elecetion of a new primary and inititates a getlasterror() method?

Is mongodb potentially allows the situations when it is said that file isn't written, but really it is? I mean could mongo collect and store staled files? How to avoid this?

Thanks.

вторник, 7 августа 2012 г., 19:48:43 UTC+4 пользователь markh написал:

mongodb-user...@googlegroups.com

[markh]

Hi,

mongodb is "fire & forget" by default. If you want a return code, yes, you can call the getLastError command. 

Please read the documentation on the getlastError command here and write concern here.

Consistency is covered here. This link also covers the options on the various types of options that the getLastError call can use such as writing to one replicate, waiting for a journal commit etc.

Thanks

Mark

[Дмитрий Максименко]

Mark thank you.

Strictly that was not just I was asking for.

I wonder if there is could be a situation where a user is told that file is written but it is really not?

If there are any cases when mongo collects stale records and admin doesn't know?

 
среда, 8 августа 2012 г., 13:14:12 UTC+4 пользователь markh написал:

[markh]

Hi,

I am not aware of any such situation.

If you have a fear of such a situation, you should test your application accordingly and inform us if such an issue arises.

Thanks

Mark

[Дмитрий Максименко]

Ok. Thank you.

Mark, is it true, that after replication to secondary servers, configuration servers are notified about file that was replicated for future client redirections to that file?

среда, 8 августа 2012 г., 13:55:52 UTC+4 пользователь markh написал:

[markh]

Hi,

No that is not the case.

I think you are mis-understanding how sharding and replication works. Configuration servers are not involved in replication.

Please re-read the documentation that I have previously provided.

Thanks

Mark

[Дмитрий Максименко]

Ok. 

And if I want distribute read requests to different secondary servers, should I use 1 shard with primary, secondary, configuration and mongos server configured?

Or there is another method?

среда, 8 августа 2012 г., 15:12:38 UTC+4 пользователь markh написал:

[markh]

Hi,

You don't need to shard to distribute reads, you can do read scaling with replica sets. The main method of scaling in MongoDB is sharding. Replicas are foremost for data safety, high availability and redundancy. However, it is possible to perform queries  on secondaries. By default, the primary node of a replica set is accessed for all reads and writes. Please see the "Read Preference" section here for more detailed information.

Most drivers provide a slaveOkay method for identifying that a specific operation can be run on a secondary node. When using slaveOkay, a system can share the read load amongst several nodes.

Mark

[Дмитрий Максименко]

Thanks mark.

In that case primary server will be responsible for distributing read requests?

Do I need conf servers and mongos without sharding all the same?

Mark. Thank you for your patient!

среда, 8 августа 2012 г., 16:51:35 UTC+4 пользователь markh написал:

[markh]

Hi,

No, in that case the driver will distribute the reads. Please read the links that I included in my last update, they explain the behaviour. Each driver behaves slightly differently and you can read the driver documentation here.

Without sharding, there is no config servers nor is there any mongos.

Mark

[Дмитрий Максименко]

Mark thank you.

But can I use sharding just with 1 shard?

I understand that there is no need, but I am wondering in architecture way.

среда, 8 августа 2012 г., 17:29:51 UTC+4 пользователь markh написал:

[markh]

Hi

Yes, you can.

Thanks

Mark