Backups
Hazelcast distributes your storage and computational data, along with their backups, among the cluster members; this way, if a member is lost, Hazelcast restores the data from these backups. As the data itself, its backups are distributed and stored also in the memory. The distribution happens on the partition level; the data and its backups are stored in the memory partitions. See the Data Partitioning and Partition Grouping for more information about the partitioning.
|
Hazelcast does not support backup redistribution on a data structure level. Thus, changing the backup count of a nonempty data structure is not supported. For example, for a map:
|
When a member in your cluster is lost, Hazelcast redistributes the backups on the remaining members so that every partition has a backup. The number of backups is configurable. Based on the configuration, data can be kept in multiple replicas of a partition.
There are two types of data backups for Hazelcast’s standard utility collections such as maps, caches, queues and ringbuffers:
-
Synchronous (Sync): Using this type blocks the operations in the cluster until all backups are successfully copied to the members and acknowledgements are received. Therefore, backups are updated before a write(put, set, remove and their async counterparts) operation is completed, provided that the cluster is stable. Sync backup operations have a blocking cost which may lead to latency issues. This is the default type for the data structures mentioned above with the default value “1”, i.e., the default number of backups is one.
-
Asynchronous (Async): Using this type does not block operations. They are fire & forget and do not require acknowledgements; the backup operations are performed at some point in time.
See the relevant sections below on how you can configure sync and async backups for the data structures:
See this section for backup information about the Hazelcast jobs.
