Sorry for misunderstood. I think the client could not receive the 'error' message or even if it receive any ack, the ack should be 'undeterminated'
发自我的 iPhone > 在 2020年2月16日，10:35，jonefeewang <jonefeew...@gmail.com> 写道： > > Norbert Kalmar-2 wrote >> Hi, >> >> A would not have confirmed in this case to the client the write. Sending >> ACK means the followers have written the transaction to disc. Leader (in >> this case A) still needs to send COMMIT message to the followers. >> It goes like this: >> - LEADER(A) receives a write, so it creates a transaction and send it to >> all FOLLOWERs. >> - FOLLOWERs receive the transaction and writes it to disc (txnlog). It >> does >> NOT apply to the datatree. >> - After writing to disc FOLLOWERs send ACK to LEADER(A) (Nothing at this >> point is acknowledged to the client) >> - After LEADER(A) receives quorum of ACK, then, and only then will it >> apply >> to the datatree and send COMMIT message to all FOLLOWERs to do the same. >> And also ACK to client that the write is complete. And at this point the >> data sent by the client is saved in the txnlogs of the quorum. >> >> Hope this helps, >> >> Regards, >> Norbert >> >> On Sat, Feb 15, 2020 at 5:20 AM < > >> hnwyllmm@ > >> > wrote: >> >>> How do you know A has sent the ack to client before he die ? >>> >>> 发自我的 iPhone >>> >>>> 在 2020年2月15日，09:15，jonefeewang < > >> jonefeewang@ > >> > 写道： >>>> >>>> I also have the same question like this below: >>>> >>>> >>>> let's say we have nodes A B C D E, now A is the leader >>>> >>>> A broadcasts <1,1>, it reaches B, then A, B die, C D E elect someone, >>>> the new system is going to throw away <1,1> since it does not know its >>>> existence, right? >>>> >>>> start from scratch, >>>> A broadcasts<1,1> , it reaches all, all send ACK to A, but A dies >>>> before receiving the ACK, then BCDE elects someone, and the new leader >>>> sees <1,1> in log, so it broadcasts <1,1> to BCDE, which all commit >>>> it. now if we look back, when A dies, the client should get a "write >>>> failure", but now after BCDE relection, the written value does get >>>> into the system ??? the client and the cluster has an inconsistent view >>> ?? >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from: http://zookeeper-user.578899.n2.nabble.com/ >>> >>> > > > Sorry, I think I need to make the question more clear : > > 1. A broadcasts<1,1> , it reaches all, all send ACK to A > 2. A dies before receiving the ACK, > 3. BCDE elects someone, and the new leader sees <1,1> in log, so it > broadcasts <1,1> to BCDE, which all commit it. > > now if we look back, when A dies, the client should get a "write > failure", but now after BCDE relection, the written value does get into the > system 。 > > so in the last, the client got a write error(probably think this write did > not succeed), but the server clusters did write this value in their log and > datatree. > > so the client and the cluster has an inconsistent view. > > > > > -- > Sent from: http://zookeeper-user.578899.n2.nabble.com/
