Hello Lily, Ignite ensures data consistency all the times taking care of data rebalancing scenarios as well. For instance, if there are Table1 and Table2 and they are collocated (Table2.affinityKey links it to Table1.someKey) then during rebalancing all the collocated records of both tables will be moved to the new node.
If to go in details, Ignite rebalances partitions. Once your cluster topology changes, the affinity function recalculates partitions distributions to make it even cluster-wide. As a result, some of the partitions will stay on existing nodes while the others will be moved to the new one. Collocated data is always mapped/stored to/in the partition that has the same number as the partition of the parental record - for instance, if Table1.someKey is mapped to partition 5 of Table1 then all the records of Table2 that Table2.affinityKey==Table1.someKey will be stored in the partition 5 of Table2. If partition 5 needs to be rebalanced, then it will be rebalanced for all the tables you have so that the new node owns all the partitions 5 of all the tables. The only requirement here is that the total partition number and affinity function must be the same for all the tables (which is true by default). - Denis On Tue, Jul 30, 2019 at 4:28 PM lhendra <[email protected]> wrote: > Hi, > > I'm totally new to Ignite and have been reading lots of documentation. > I'm trying to find info on how node rebalancing is handled in relation to > affinity collocation. > There are 2 use cases that I want to confirm: > (1) Create a new table with an affinity key to an existing table. > (2) Add new columns to existing tables. > In both cases, let's say we start loading data that causes nodes to fill > up, > and we throw in a new node. Does Ignite automatically perform node > rebalancing WHILE preserving the affinity constraints in any/both cases? > > Thanks, > Lily > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
