On Fri, Oct 6, 2017 at 10:01 AM, Ivan Kelly <iv...@apache.org> wrote:
> On Fri, Oct 6, 2017 at 6:35 PM, Venkateswara Rao Jujjuri > <jujj...@gmail.com> wrote: > >> However, imagine that the fenced message is only in the journal on b2, > >> b2 crashes, something wipes the journal directory and then b2 comes > >> back up. > > > > In this case what happened? > > 1. We have WQ = 1 > > 2. We had data loss (crash and comeup clean) > Ah, maybe this was unclear. I meant, WQ = 2, the fencing is persisted > fully on b1, but only onto the journal on b2. > > > But yeah, in addition to dataloss we have fencing violation too. > > The problem is not just wiped journal dir, but how we recognize the > bookie. > > Bookie is just recognized by its ip address, not by its incarnation. > > Bookie1 at T1 (b1t1) ; and same bookie1 at T2 after bookie format (b1t2) > > should be two different bookies, isn;t it? > This is something I want to change also for the zk stuff. There should > be a uuid generated for the bookie when it is formatted, so that we > can distinguish between instances. This uuid should be part of the > cookie. Once we detect the uuid for a bookie has changed, all ledgers > on that bookie should be checked somehow. > Just that may not be sufficient. 1. The UUID needs to be part of the ledger metadata so that the auditor knows it is looking at different bookie. 2. Bookie need to know if the writes and reads from the client are intended for it or not. If not in your case C1 can come back to life and start to write without any problem. > -Ivan > -- Jvrao --- First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
