How Replication and Preloading Work

This topic explains how region replication and preloading work in VMware Tanzu GemFire.

To work with replicated and preloaded regions, you should understand how their data is initialized and maintained in the cache.

Replicated and preloaded regions are configured by using one of the REPLICATE region shortcut settings, or by setting the region attribute data-policy to replicate, persistent-replicate, or preloaded.

Initialization of Replicated and Preloaded Regions

At region creation, the system initializes the preloaded or replicated region with the most complete and up-to-date data set it can find. The system uses these data sources to initialize the new region, following this order of preference:

Another replicated region that is already defined in the cluster.
For persistent replicate only. Disk files, followed by a union of all copies of the region in the distributed cache.
For preloaded region only. Another preloaded region that is already defined in the cluster.
The union of all copies of the region in the distributed cache.

Member M1 with Distributed Region A containing X and Y. Member M2 with Distributed Region A containing X and Z. Newly created Member M3 with Distributed Region A contains X, Y, and Z.

While a region is being initialized from a replicated or preloaded region, if the source region crashes, the initialization starts over.

If a union of regions is used for initialization, as in the figure, and one of the individual source regions goes away during the initialization (due to cache closure, member crash, or region destruction), the new region may contain a partial data set from the crashed source region. When this happens, there is no warning logged or exception thrown. The new region still has a complete set of the remaining members’ regions.

Behavior of Replicated and Preloaded Regions After Initialization

Once initialized, the preloaded region operates like the region with a normal data-policy, receiving distributions only for entries it has defined in the local cache.

'Distributed Region (Preloaded or Normal) containing X and Y' and 'Distributed System' with double-headed arrow labeled 'Operations for existing entry keys'.

If the region is configured as a replicated region, it receives all new creations in the distributed region from the other members. This is the push distribution model. Unlike the preloaded region, the replicated region has a contract that states it will hold all entries that are present anywhere in the distributed region.

'Distributed Region (Replica) containing X and Y' and 'Distributed System'. Arrow labeled 'All creations' from Distributed System to Distributed Region, and double-headed arrow labeled 'Other entry operations (due to distribution) connecting Distributed System to Distributed Region.