Data Partitioning

The affinity function controls how data entries are mapped onto partitions and partitions onto nodes. The default affinity function implements the rendezvous hashing algorithm. It allows a bit of discrepancy in the partition-to-node mapping (i.e., some nodes may be responsible for a slightly larger number of partitions than others). However, the affinity function guarantees that when the topology changes, partitions are migrated only to the new node that joined or from the node that left. No data exchange happens between the remaining nodes.

When creating a cache or SQL table, you can choose between partitioned and replicated mode of cache operation. The two modes are designed for different use case scenarios and provide different performance and availability benefits.

By default, Ignite keeps a single copy of each partition (a single copy of the entire data set). In this case, if one or multiple nodes become unavailable, you lose access to partitions stored on these nodes. To avoid this, you can configure Ignite to maintain backup copies of each partition.

Backup copies are configured per cache (table). If you configure 2 backup copies, the cluster maintains 3 copies of each partition. One of the partitions is called the primary partition, and the other two are called backup partitions. By extension, the node that has the primary partition is called the primary node for the keys stored in the partition. The node with backup partitions is called the backup node.

When a node with the primary partition for some key leaves the cluster, Ignite triggers the partition map exchange (PME) process. PME labels one of the backup partitions (if they are configured) for the key as primary.

Backup partitions increase the availability of your data, and in some cases, the speed of read operations, since Ignite reads data from backed-up partitions if they are available on the local node (this is the default behavior that can be disabled. See Cache Configuration for details.). However, they also increase memory consumption or the size of the persistent storage (if enabled).

Partition map exchange (PME) is a process of sharing information about partition distribution (partition map) across the cluster so that every node knows where to look for specific keys. PME is required whenever the partition distribution for any cache changes, for example, when new nodes are added to the topology or old nodes leave the topology (whether on user request or due to a failure).

Examples of events that trigger PME include (but are not limited to):

When one of the PME-triggering events occurs, the cluster waits for all ongoing transactions to complete and then starts PME. Also, during PME, new transactions are postponed until the process finishes.

The PME process works in the following way: The coordinator node requests from all nodes the information about the partitions they own. Each node sends this information to the coordinator. Once the coordinator node receives the messages from all nodes, it merges the information into a full partition map and sends it to all nodes. When the coordinator has received confirmation messages from all nodes, PME is considered completed.

Refer to the Data Rebalancing page for details.

It may happen that throughout the cluster’s lifecycle, some of the data partitions are lost due to the failure of some primary node and backup nodes that held a copy of the partitions. Such a situation leads to a partial data loss and needs to be addressed according to your use case. For detailed information about partition loss policies, see Partition Loss Policy.