[CONTROLLER-1880] Include conflicting term informantion in AppendEntriesReply Created: 09/Jan/19 Updated: 25/Jun/20 |
|
| Status: | Open |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Low |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
RAFT section 5.3 states that: If desired, the protocol can be optimized to reduce the number of rejected AppendEntries RPCs. For example, when rejecting an AppendEntries request, the follower can include the term of the conflicting entry and the first index it stores for that term. With this information, the leader can decrement nextIndex to bypass all of the con- flicting entries in that term; one AppendEntries RPC will be required for each term with conflicting entries, rather than one RPC per entry. In practice, we doubt this opti- mization is necessary, since failures happen infrequently and it is unlikely that there will be many inconsistent en- tries. We currently do not implement this optimization, but it could be useful. From implementation perspective, rather than expanding AppendEntries directly with this information, we should add a subclass, which is used when the follower determines this additional information is useful for leader to skip some entries. |
| Comments |
| Comment by Tom Pantelis [ 09/Jan/19 ] |
|
We've already implemented other optimizations to avoid the slow path of decrementing the next index, some of it due to the in-memory log trimming and replicatedToAllIndex which isn't covered by raft. The above optimization would only help in the case where the leader's previous log entry exists in the follower's log but the terms don't match (which wouldn't cover the case in https://git.opendaylight.org/gerrit/#/c/79351). So currently, we'd only hit the slow path if the follower had accumulated more uncommitted entries from a prior term than the number of new entries from the leader's new term. The above optimization would help in that case although it wouldn't be common. BTW - the new info would be added to AppendEntriesReply. |