{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

Eg need to elect a no op at 57 to guarantee that if

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: cepted instances. It might be that the client was told B was chosen at time slot 58, so its not linearizable to put a later request to do C in slot 57. It is always safe to insert a no- op into the sequence to fill a gap. NOTE: recovery process must be idempotent – that is, if new leader fails, next leader just picks up and does the recovery process again, no matter how much progress the failed leader had made. When old leader recovers, can start back in (if you want to keep constraint that leader is always lowest #’ed node), taking over from the current leader in the same way as if the current leader failed d) one final case: if leader is slow, but hasn’t failed then there could be two leaders making proposals at the same time. Paxos guarantees that this is still correct, even if it might stall progress until its sorted out. Monday: Continuing with Paxos. Draw picture of clients communicating with Paxos group <insert: I answered a question a bit confusingly last time> What about reads? a) if the client is ok with an old read, then can answer from the log – the read can be satisfied by any b) if the client wants a guarantee that no one has updated the value in the meantime (that its reading the latest value), then the read needs to go to a majority c) most systems handle this differently: they give the leader a lease. During the lease, the master is the only leader, and therefore, any reader can trust that the master has the latest version. This...
View Full Document

{[ snackBarMessage ]}