natas_hw
/
cassandra
mirror of https://github.com/apache/cassandra
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor corrections to TCM Implementation document 

Patch by Venkata Harikrishna Nukala; reviewed by Sam Tunnicliffe for
CASSANDRA-19247
This commit is contained in:
N V Harikrishna 2024-02-12 08:46:55 +00:00 committed by Sam Tunnicliffe
parent 61aabdfb44
commit bec6bfde1f
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/java/org/apache/cassandra/tcm/TCM_implementation.md
View File

@ -54,11 +54,11 @@ At that point, the node is ready to start the process of joining the ring. It be
* Ranges that will be affected by the bootstrap of the node are locked (see `LockedRanges`)
* If computed locked ranges intersect with ranges that were locked before this transformation got executed, `PrepareJoin` is rejected.
* `InProgressSequence`, holding the three transformations (`PrepareJoin`, `MinJoin` `FinishJoin`), is computed and added to `InProgressSequences` map.
* `InProgressSequence`, holding the three transformations (`StartJoin`, `MidJoin` and `FinishJoin`), is computed and added to `InProgressSequences` map.
* If any in-progress sequences associated with the current node are present, `PrepareJoin` is rejected.
* `AffectedRanges`, ranges whose placements are going to be changed while executing this sequence, are computed and returned as a part of commit success message.
`InProgressSequence` is then executed step-by step. All local operations that the node has to perform between executing these steps are implemented as a part of the in-progress sequence (see `BootstrapAndJoin#executeNext`). We make *no assumptions* about liveness of the node between execution of in-progress sequence steps. For example, the node may crash after executing `PrepareJoin` but before it updates tokens in the local keyspace. So the only assumption we make is that `SystemKeyspace.updateLocalTokens` has to be called *before* `StartJoin` is committed. Similarly, owned data has to be streamed towards the node *before* it becomes a part of a read quorum, so even if the node crashes or is restarted an arbitrary number of times during streaming.
`InProgressSequence` is then executed step-by-step. All local operations that the node has to perform between executing these steps are implemented as a part of the in-progress sequence (see `BootstrapAndJoin#executeNext`). We make *no assumptions* about liveness of the node between execution of in-progress sequence steps. For example, the node may crash after executing `PrepareJoin` but before it updates tokens in the local keyspace. So the only assumption we make is that `SystemKeyspace.updateLocalTokens` has to be called *before* `StartJoin` is committed. Similarly, owned data has to be streamed towards the node *before* it becomes a part of a read quorum, so even if the node crashes or is restarted an arbitrary number of times during streaming.
In order to ensure quorum consistency, before executing each next step, the node has to await on the `ProgressBarrier`. CEP-21 contains a detailed explanation about why progress barriers are necessary. For the purpose of this document, it suffices to say that majority of owners of the `AffectedRanges` have to learn about the epoch enacting the previous step before each next step can be executed. This is done in order to preserve replication factor for eventually consistent queries.