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: user@ignite.apache.org At: 02/06/20 18:14:37To: user@ignite.apache.org 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: user@ignite.apache.org At: 02/06/20 07:12:26To: user@ignite.apache.org 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/