I also have seen a similar error:
Caused by: org.apache.ignite.spi.IgniteSpiException: BaselineTopology of
joining node (b1a557be-4a89-42d8-9837-ece339088cc4) is not compatible with
BaselineTopology in the cluster.
Joining node BlT id (4) is greater than cluster BlT id (0). New
BaselineTopology was set on joining node with set-baseline command. Consider
cleaning persistent storage of the node and adding it to the cluster again.
At
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:1946)
~[stormjar.jar:?]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:969)
~[stormjar.jar:?]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:391)
~[stormjar.jar:?]
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2020)
~[stormjar.jar:?]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
~[stormjar.jar:?]
... 41 more
How would the node blt id ever be greater than the cluster blt id? Where does
this blt id get stored for a node when it is down?
From: [email protected] At: 02/06/20 18:14:37To: [email protected]
Subject: Re: Issue with BaselineTopology Branching History
A couple more questions after reading the explanation:
-You mentioned each node in the BLT has a consistent id. How is this calculated?
-The branching point hash is a sum of hashcodes of consistent ids of nodes
currently in the BaselineTopology. It is also mentioned that there is a BLT id.
How does this relate to the branching point hash?
-How does the cluster distinguish between a new node joining vs. a node that
crashed and rejoined?
From: [email protected] At: 02/06/20 07:12:26To: [email protected]
Subject: Re: Issue with BaselineTopology Branching History
Hi Mitchell,
I'm not really sure whether versioning/branching history is covered anywhere
and it looks like it is worth covering.
Branching point hash = sum of hashcodes of BLT nodes consistent id's (long).
Each time baseline topology changes, the previous value is added to the
branching history, id is increased.
The joining node is rejected when couple of things happen (most of them are
baseline changes while being not a part of the cluster):
1. Joining node has greater BLT id than cluster.
2. Cluster BLT id is equals to joining node BLT id, but is not compatible.
That means that cluster branching history does not contains joining node
current BLT hash.
3. Joining node has lesser BLT id than cluster and branching history for
current id does not contain BLT hash of joining node.
PARTITIONED cache with node filter is an alternative to LOCAL cache.
Best regards,
Anton
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
