Page History

...

Due to implementation of these properties linear scalability is achieved when adding new nodes to the grid.

Re-balance

Re-balance - a procedure for exchanging data between nodes to ensure uniform distribution of data (redistribution of data between nodes) [1] and to ensure data consistency [2].

[1] Partition state based re-balance
In the first case, the reason for the rebalance is a change in the list of nodes - owners of the partition. If a new node has joined the topology then part of the partitions will be reassigned to it due to the affinity function property of the uniform distribution of partitions among the nodes. If the node is left then the re-balance will be triggered to ensure the availability of the required number of copies of the partition in the grid.

[2] Counter based re-balance
In the second case, which is relevant only for the enabled persistence mode, re-balance is used to restore the consistency of the data if the node(s) was absent for some time in the topology under the load.
When the node re-joins the topology, the partition update counter will be analyzed to determine how much the partition has “lagged” from other copies.
Depending on how much the partition is behind, the second type of rebalance can use the write-ahead log as a data source. In this case, the re-balance can be performed without a complete reloading of the partition and is called “historical”.
Another scenario for the occurrence of [2] is the activation of the grid, which was turned off accidentally (under load)
Re-balance is the exchange of supply and demand messages between nodes. A message demand sends a node on which the partition is not consistent. Supply messages contain the next update batch and are sent in response to demand messages.