Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Rolling config change considered harmful?


Copy link to this message
-
RE: Rolling config change considered harmful?
In the case I described, the txn is not reflected in the zookeeper state.
Say T is a create txn. Once C is elected, it determines the initial history
of txns for the new epoch that is starting and this initial history is not
going to include T.

In the example below, I was ignoring the client that triggered T, but since
it has been acked by a quorum, the client might as well have received the
confirmation of the operation and think that the znode has been created.

-Flavio

> -----Original Message-----
> From: Jordan Zimmerman [mailto:[EMAIL PROTECTED]]
> Sent: 14 June 2013 20:16
> To: [EMAIL PROTECTED]
> Subject: Re: Rolling config change considered harmful?
>
> Yes - save that I'm not sure what happens with a client when a transaction
is
> lost. What is the error to the client? Or are you referring to internal
> transactions as part of the leader election?
>
> -JZ
>
> On Jun 14, 2013, at 12:07 PM, "FPJ" <[EMAIL PROTECTED]> wrote:
>
> > Not sure if this helps but here is an example:
> >
> > - Txn T is acknowledged by A and B (ensemble is {A, B, C})
> > - Ensemble changes to {B, C, D}
> > - C and D form a quorum and elect C because it has the highest zxid.
> >
> > C won't have T, so the txn gets lost.
> >
> > Does it make sense?
> >
> > -Flavio
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB