Page History

...

The cluster should be active

Limitations

...

CUrrent limitations

• Restoring is possible only if all parts of the snapshot are present in the cluster. Each node looks for a local snapshot data in the configured snapshot path by the given snapshot name and consistent node ID.
• The

...

• restore procedure can be applied only to cache groups created by the user.
• Cache groups to be restored from the snapshot must not be present in the cluster. If they are present, they must be link:key-value-api/basic-cache-operations#destroying-caches[destroyed] by the user before starting this operation.
• Concurrent restore operations are not allowed. Thus, if one operation has been started, the other can only be started after the first is completed.

Failover

To avoid the possibility of starting a node with inconsistent data, the partition files are first copied to a temporary directory and then this directory is moved using an atomic move operation. When the node starts, the temporary folder is deleted (if such exists).

...

• The crashed node must revert the local uncompleted snapshot at its startup.
• If the crashed node hasn't complete local snapshot prior to the crash then all nodes affected by this cluster snapshot operation must delete their local snapshot results.

Limitations

1. The whole cluster allowed only one cluster-wide snapshot operation per time.
2. Encrypted caches currently not allowed due to required additional changes to merge cache partition with its delta file.
3. The cache stop operation is not allowed during the ongoing cluster snapshot. An exception will be thrown to users on the cache stop attempt.
4. The cluster snapshot operation will be stopped if some of the baseline nodes left or fail prior to reporting about their local snapshot completion. Partial local snapshots will be reverted.

...