In master/slave setup, how is a corrupted master reconciled against a slave?

[Riyad]

This is related to the durability conversations brought up in threads
like this:
http://groups.google.com/group/mongodb-user/browse_thread/thread/e4fa92b800d507b2

I understand in a master/slave how slaves are reconciled against the
master when they become corrupted (piece-meal or entirely resynced)
but I don't understand how (is it even possible?) a corrupted master
can be reconciled against a slave if the master gets corrupted and
goes down?


Q1: Can a master even be reconciled against a slave? Or does the
master just have to be repaired and the lost data dealt with some
other way?
Q2: In a master/slave setup, if the master goes down, can the slave
accept committed data until the master comes back up -- the next part
of this question dovetails right back into Q1 if "yes".
Q3: Are Replica Sets the answer to all of this where many Mongo
instances act in collusion with one-another to make sure everyone
stays healthy?
Q4: Are transaction logs planned for 1.7/1.8?


I'm essentially trying to plan for worst-case scenarios (master + disk
corruption == ?) and figuring out with Mongo what the correct recovery
sequence is for those times.

Asking when it actually happens seems like bad planning.

[Michael Dirolf]

If the master dies in M/S the right approach is almost always to
promote the slave to master and treat it's copy of the data as
canonical (possibly losing a few seconds of data or manually merging
uncommitted data when the former master comes back up).

Replica sets basically handle this promotion automatically.

> --
> 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.
>
>

[Kyle Banker]

On Fri, Jul 9, 2010 at 11:46 AM, Riyad <rka...@gmail.com> wrote:

This is related to the durability conversations brought up in threads
like this:
http://groups.google.com/group/mongodb-user/browse_thread/thread/e4fa92b800d507b2

I understand in a master/slave how slaves are reconciled against the
master when they become corrupted (piece-meal or entirely resynced)
but I don't understand how (is it even possible?) a corrupted master
can be reconciled against a slave if the master gets corrupted and
goes down?


Q1: Can a master even be reconciled against a slave? Or does the
master just have to be repaired and the lost data dealt with some
other way?

You might do a repair or a resync, depending on a number of factors.

There's no reconciliation feature, though.

 

Q2: In a master/slave setup, if the master goes down, can the slave
accept committed data until the master comes back up -- the next part
of this question dovetails right back into Q1 if "yes".

See replica sets.

 

Q3: Are Replica Sets the answer to all of this where many Mongo
instances act in collusion with one-another to make sure everyone
stays healthy?

Yes, for automated failover, replica sets are the answer.

 

Q4: Are transaction logs planned for 1.7/1.8?

The exact strategy hasn't been decided yet, but some single-server durable solution will be implemented.

 

I'm essentially trying to plan for worst-case scenarios (master + disk
corruption == ?) and figuring out with Mongo what the correct recovery
sequence is for those times.

Asking when it actually happens seems like bad planning.

[Eliot Horowitz]

If a master dies you should fail over to the slave and assume the master is toast. For write durability you should use w=2.

1.8 will have full single server durability.

[Riyad]

Michael, Kyle & Eliot,

Thank you for all the individual replies -- each one added something
more that answered my inevitable followup questions.

Best,
Riyad

On Jul 9, 9:07 am, Eliot Horowitz <eliothorow...@gmail.com> wrote:
> If a master dies you should fail over to the slave and assume the master is toast. For write durability you should use w=2.
>
> 1.8 will have full single server durability.
>
> On Jul 9, 2010, at 8:46 AM, Riyad <rka...@gmail.com> wrote:
>
>
>
> > This is related to the durability conversations brought up in threads
> > like this:

> >http://groups.google.com/group/mongodb-user/browse_thread/thread/e4fa...

[Suno Ano]

[skipping a lot of lines ...]

Eliot> If a master dies you should fail over to the slave and assume
Eliot> the master is toast. For write durability you should use w=2.

Just to be sure, can one use w=<some integer> with replica sets as well?
If so what is the semantics in case I would specify w=2 with replica
sets? Would that mean that a write by the driver would only be seen as
successful if it made it onto two members of the replica set?

I am asking because this link

http://www.mongodb.org/display/DOCS/Replication#Replication-ReplicationAcknowledgementviagetlasterror

makes it sound as if it were just be true with replica pairs but not
with replica sets.

[Eliot Horowitz]

Yes - it works exactly the same way with replica sets as regular master/slave.

[Suno Ano]

Eliot> Yes - it works exactly the same way with replica sets as regular
Eliot> master/slave.

Fantastic!

ANOTHER QUESTION:
are there any plans to tag documents so that maybe we can have important
once replicated more often throughout the cluster than less important
ones? Example:

- say I want less important data to be replicated twice throughout the
cluster and
- important stuff five times

Afaik GFS (Google Filesystem) does 3 copies for everything and 4 or more
copies for important data. From what I know there is some sort of tag
that is carried within the metadata of every data chunk on GFS and then
the number of times it is replicated is handled automatically. That
would be a great thing to have with MongoDB.

[Kristina Chodorow]

You can set w for any remove, update or insert.  So, for important stuff just use w=5 and less important stuff w=2. 

Setting w means that at least N servers have it before it returns success but the operation will eventually be replicated to every member of the replica set, regardless of what you set w to. 

--

[Riyad]

Suno,

Exactly what Kristina said -- so the answer is "yes" but you have to
implement it in your own API semantics.

For example, you have a helper class:
DAO.saveEntity(Entity e, Importance.NORMAL);
DAO.saveEntity(Entity e, Importance.HIGHEST);

or something like that, and inside your DAO impl you include the
appropriate level of w-ness to the operation based on the nature of
your cluster size and setup.

> > mongodb-user...@googlegroups.com<mongodb-user%2Bunsubscribe@google groups.com>
> > .

[Suno Ano]

Yes, that is perfectly fine, I was thinking to complicated plus I did
not actually try to get my hands dirty so ... It might be even more
handy to have a decorator that you can bring out whenever you want to
have elevated write durability.