Re: question on ZAB protocol
>> so the client and the cluster has an inconsistent view. I would be reluctant to conclude this is an inconsistent view as a client should always consult server to get the latest state, rather than derive the state from the response of the request, which is not reliable if the request "fails" as one never know the request truly fails or not in cases such as connection loss. Though, when the request succeeds - that ZooKeeper guarantees the write is persistent to quorum. On Sun, Feb 16, 2020 at 5:26 AM wrote: > 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 写道： > > > > 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/ > >
Re: question on ZAB protocol
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 写道： > > 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/
Re: question on ZAB protocol
Yes I believe that this is possible, not only in ZK but in many other systems when your connection to the database fails and you don’t know whether your transaction committed or aborted. Improving this is part of the forever open Zookeeper-22 JIRA. Alex On Sat, Feb 15, 2020 at 6:35 PM jonefeewang wrote: > 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/ >
Re: question on ZAB protocol
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/
Re: question on ZAB protocol
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 wrote: > How do you know A has sent the ack to client before he die ? > > 发自我的 iPhone > > > 在 2020年2月15日，09:15，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/ > >
Re: question on ZAB protocol
How do you know A has sent the ack to client before he die ? 发自我的 iPhone > 在 2020年2月15日，09:15，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/
Re: question on ZAB protocol
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/
