BaselineTopology represents a set of "database nodes" - nodes responsible for holding persistent-enabled caches
and persisting their information to durable storage.
Two major features BaselineTopology allows are:
- Protection from conflicting updates.
- Cluster auto activation.
Protection from conflicting updates
Consider en example: there is a cluster of three nodes, A, B and C, all nodes store persistent data.
Cluster history looks like this:
[A,B,C]
| \
(1)cluster segmentation, two parts get activated independently
| |
[A,B] [C]
| |
(2)updates to both parts
After independent updates applied to both parts of cluster at point(2) node C should not be allowed to join
[A,B] part.
The following algorithm makes sure node C will never join [A,B] part back:
-
When the cluster is initially activated BaselineTopology is created; its property branchingPntHash
is calculated based on consistent IDs of all nodes.
-
At point(1) two parts are activated separately; BaselineTopology in each is updated:
old branchingPntHash is moved to branchingHistory list;
new one is calculated based on new set of nodes.
-
If node C tries to join other part of cluster (e.g. after network connectivity repair)
[A,B] cluster checks its branchingPntHash and branchingHistory
to see if branching history of C's BaselineTopology has diverged from [A,B].
If divergence is detected [A,B] cluster refuses to let C into topology.
All new nodes joining a cluster should pass validation process before join; detailed algorithm of the process
is described below.
Joining node validation algorithm
Node joining a cluster firstly reads its local BaselineTopology from metastore and sends it to the cluster.
-
When BaselineTopology is set (e.g. on first activation) or recreated (e.g. with set-baseline command)
its ID on all nodes is incremented by one.
So when cluster receives a join request with BaselineTopology it firstly compares joining node BlT ID with
local BlT ID.
If joining node has a BaselineTopology with ID greater than one in cluster it means that BlT was changed
more times there; therefore new node is not allowed to join the cluster.
-
If user manually activates cluster when some of Baseline nodes are offline no new BlT is created.
Instead current set of online nodes from BaselineTopology is used to update
branchingPntHash
property of current BaselineTopology.
Old value of the property is moved to branchingHist
list.
If joining node and local BlT IDs are the same then cluster takes branchingPntHash of joining node
and verifies that its local branchingHist contains that hash.
If joining node hash is not presented in cluster branching history list
it means that joining node was activated independently of currently running cluster;
therefore new node is not allowed to join the cluster.
If joining node hash is presented in the history, that it is safe to let the node join the cluster.
-
When BaselineTopology is recreated (e.g. with set-baseline command) previous BaselineTopology is moved
to BaselineHistory (consult source code of
GridClusterStateProcessor
for more details).
If cluster sees that joining node BlT ID is less than cluster BlT ID it looks up for BaselineHistory item
for new node ID.
Having this BaselineHistory item cluster verifies that branching history of the item contains
branching point hash of joining node
(similar check as in the case above with only difference that joining node BlT is compared against
BaselineHistory item instead of BaselineTopology).
If new node branching point hash is found in the history than node is allowed to join;
otherwise it is rejected.
Cluster auto activation