Chapter 2. Data Grid Cross-Site Replication

Data Grid clusters running in different locations can discover and communicate with each other.

A site is a locally running Data Grid cluster. For demonstration purposes, this documentation illustrates sites as data centers in different geographic locations, as in the following diagram:

LON is a datacenter in London, England.
NYC is a datacenter in New York City, USA.

Name remote sites as backup locations in your cache definitions.

For example, the following diagram shows three caches, "customers", "eu-orders", and "us-orders":

Data Grid clusters can use different strategies for backing up data to remote sites.

Data Grid replicates across sites at the same time that writes to local caches occur. For example, if a client writes "k1" to LON, Data Grid backs up "k1" to NYC at the same time.

Backup configurations include timeout values for operations to replicate data to remote sites. When backup operations reach the timeout, Data Grid records the operation as a failure.

To automatically take sites offline, you can then configure the number of consecutive failures that can occur.

For example, the NYC backup configuration specifies five as the number of failures after which NYC goes offline. If LON attempts five consecutive backup operations that fail, Data Grid automatically takes NYC offline. LON then stops backing up to NYC until you bring the site back online.

<backup site="NYC" strategy="ASYNC">
	<take-offline after-failures="5"/>
</backup>

You can also specify the amount of time to wait before taking sites offline. When backup operations fail, Data Grid waits before taking sites offline. If a backup request succeeds before the wait time runs out, Data Grid does not take the site offline.

<backup site="NYC" strategy="ASYNC">
	<take-offline after-failures="5"
                min-wait="10000"/>
</backup>

In the preceding example, if failures occur for 5 consecutive operations, Data Grid waits 10 seconds and, if no requests are successful within the 10 second wait time, Data Grid then takes NYC offline.

To use only a minimum wait time for automatically taking locations offline, set a negative or zero value for the after-failures attribute; for example:

<backup site="NYC" strategy="ASYNC">
	<take-offline after-failures="-1"
                min-wait="10000"/>
</backup>

State transfer is an administrative operation that synchronizes data between sites.

For example, LON goes offline and NYC starts handling client requests. When you bring LON back online, the Data Grid cluster in LON does not have the same data as the cluster in NYC.

To ensure the data is consistent between LON and NYC, you can push state from NYC to LON.

Clients can write to Data Grid clusters in either an Active/Passive or Active/Active configuration.

In the preceding image:

With Active/Passive, NYC provides data redundancy. If the Data Grid cluster at LON goes offline for any reason, clients can start sending requests to NYC. When you bring LON back online you can synchronize data with NYC and then switch clients back to LON.

In the preceding image:

With Active/Active both NYC and LON replicate data to remote caches while handling client requests. If either NYC or LON go offline, clients can start sending requests to the online site. You can then bring offline sites back online, push state to synchronize data, and switch clients as required.

Data Grid expiration controls how long entries remain in the cache.