> <
https://groups.google.com/g/raft-dev/c/4QlyV0aptEQ> is talking about the
> ordering of heartbeat and FSM read.
>
> In current change, We take the same approach
> <
https://github.com/hashicorp/consul/blob/a6898939910b175db7495f02131918c0cc73027c/internal/storage/raft/backend.go#L129-L134>
> as consul, but after doing some search, I found TiDB's readindex read has
> two addition step:
> 1. get current commit index
> 2. wait for the FSM until it applied to the commit index we get
>
> So I wonder if these steps are necessary to be linearizable?
I assume that you are referring the "ReadIndex Read" section of this
page:
https://www.pingcap.com/blog/lease-read/
right? In particular that section says:
1. Record its current commit index into the local variable ReadIndex.
2. Send a heartbeat message to other Regions. If the majority of Regions
replies with the corresponding heartbeat response, then the leader
confirms its state.
3. Wait for the execution of its state machine until the apply index
equals to or exceeds ReadIndex. By then, the data can be read
consistently.
4. Execute the read request and return the result to the client.
I think it's necessary to wait for the state machine to apply the
current commit index, before performing the read, otherwise you wouldn't
read the latest state.
However, in many implementations the when the commit index is increased
the corresponding log entry is immediately applied to the state machine,
in an atomic manner. In those implementations you can be sure that the
commit index is always equal to the apply index, and in that case there
isn't anything to wait for.
>
> My thought is, with the Archie's
> <
https://groups.google.com/g/raft-dev/c/4QlyV0aptEQ/m/Nliuzo0WAwAJ> and
> Free's <
https://groups.google.com/g/raft-dev/c/4QlyV0aptEQ/m/a6QoLjcYAwAJ>
> point, those committed commands waiting for FSM to apply can be consider is
> *concurrent* to the incoming readindex read request, so even if the read
> doesn't affected by those committed but not applied request, that's also
> lineariziable, since they are not logical related.
I believe this would be a violation of linearizability, because you
would not read the latest committed state at the time that the read
request was received.
I'm not entirely sure about this though, and your one is an interesting
question. I'm curious to see what other folks think.
Free