Summary: Reliable Asynchronous Persistency (Mirror) - advanced topics.

Custom Mirror Service Name

A Mirror Service can be configured per Space cluster. You can't have multiple Mirror services configured for the same space cluster.
If you need "multiple mirrors" for the same space cluster you can to implement a Mirror Service that will route the data and operations to other multiple "agents" that will persist the data - effectively make the default Mirror to act as a dispatcher.

If you have Multiple different space clusters , each with its own Mirror service running you should have a different name used for each Mirror Service.
The Mirror Service name used as part of the space config is specified via the "cluster-config.mirror-service.url" property. Its default is "jini://*/mirror-service_container/mirror-service" which match the "mirror-service" that is used as part of the url property used to start the mirror service.

Example - Lets say I would like to call my mirror service mymirror-service (instead of the default mirror-service). Here is how the mirror service should be started:

<os-core:space id="space" url="/./mymirror-service" schema="mirror" external-data-source="hibernateDataSource" />

Here is how the space should be started:

<os-core:space id="space" url="/./mySpace" schema="persistent" mirror="true" external-data-source="hibernateDataSource">
    <os-core:properties>
        <props>
            <prop key="cluster-config.mirror-service.url">jini://*/mymirror-service_container/mymirror-service</prop>
        </props>
    </os-core:properties>
</os-core:space>

Implementing a Custom Mirror Data Source

The External Data Source used by the mirror needs to implement com.gigaspaces.datasource.BulkDataPersister. GigaSpaces comes with the Hibernate External Data Source implementation that implements this interface. You can implement your own Mirror very easely to accomodate your exact needs. See example below:

Show code...

And here is how this can be configured within the mirror configuration:

Show configuration...

In order to use the data source as the read mechanism for the cluster Space that connects to the mirror, additional interfaces need to implemented called DataProvider or possibly SQLDataProvider.

Usage Scenarios

Writing Asynchronously to the Mirror Data Source

The following is a schematic flow of a synchronous replicated cluster with three members, which are communicating with a Mirror Service:

Reading from the Mirror Data Source

The Mirror Service space is used to asynchronously persist data into the data source. As noted elsewhere, the Mirror is not a regular space, and should not be interacted with directly. Thus, data can't be read from the data source using the Mirror Service space. Nonetheless, the data might be read by other spaces which are configured with an external data source.

For consistency reasons, it is important that the spaces reading from the external data source are configured to read-only, unless your application logic requires differently.

The pu.xml needs to be configured to use an external data source which, when dealing with a Mirror, is central to the cluster.

Here is a schematic flow of how a Mirror Service space asynchronously receives data, to persist into an external data source, while the cluster is synchronously reading data directly from it.

Partitioning Over a Central Mirror Data Source

When partitioning data, each partition asynchronously replicates data into the Mirror Service. Each partition can read back data that belongs to it (according to the load-balancing policy defined).

Here is a schematic flow of how two partitions (each a primary-backup pair) asynchronously interact with an external data source:

Viewing the Topology

The GigaSpaces Management Center displays the Mirror Service space in the Cluster view alongside the replication group's cluster members. The Mirror Service, like any other member, has its status displayed (alive - yellow nodes, and unreachable - green nodes) which allows you to provision and track failures or network disruptions.

Considerations and Known Issues

External data source considerations also apply to the Mirror Service.

  • The Mirror Service cannot be used with a single space or the partitioned cluster schema. It is supported with the sync-replicated, async-replicated, and partitioned-sync2backup cluster schemas.
  • The Mirror Service is a single space which joins a replication group. The Mirror Service is not a clustered space or part of the replication group declaration.
  • When the Mirror Service is loaded, it does not perform memory recovery. See the reliability section for more details.
  • Transient Entries are not persisted into the data source - just like in any other persistent mode.
  • Unlike other external data source interfaces, the com.gigaspaces.datasource.BulkDataPersister interface doesn't differentiate between Space API and Map API operations. The call to com.gigaspaces.datasource.BulkItem.getItem() returns either the user entity when using the Space API, or the java.util.Map.Entry when using the Map API.
  • When using an Jini Entry as your space class, it must have getters and setters for all public fields.
  • You should have one Mirror Service running per Data-Grid cluster.
  • The Mirror Service cannot be clustered. Deploying it as a Processing unit ensures its high-availability.
  • The Mirror does not load data back into the space. the External Data Source implementation of the space should be used to initialize the space when started.

Troubleshooting

Log Messages

The external data source logging level can be modified as part of the <GigaSpaces Root>\config\gs_logging.properties file. By default, it is set to java.util.logging.Level.INFO:

com.gigaspaces.persistent.level = INFO

Logging is divided according to java.util.logging.Level as follows:

Level Description
INFO The default level for informative messages.
CONFIG Mirror Service-relevant configuration messages.
FINER Fairly detailed messages of:
  • Entering and exiting interface methods (displaying the parameter's toString() method)
  • Throwing of exceptions between the space and the underlying implementation.

Handling Failover

This section describes how the GigaSpaces Mirror Service handles different failure scenarios. The following table lists the services involved, and how the failure is handled in the cluster.

Show table...

Unlikely Failure Scenarios

The following failure scenarios are highly unlikely. However, it might be useful to understand how such scenarios are handled by GigaSpaces. This is detailed in the table below.

Show table...

GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence