Summary: Reliable Asynchronous Persistency (Mirror)
OverviewThe GigaSpaces Mirror Service provides reliable asynchronous persistency. This allows you to asynchronously delegate the operations conducted with the In-Memory-Data-Grid (IMDG) into a backend database, significantly reducing the performance overhead. The Mirror service ensures that data will not be lost in the event of a failure. This way, you can add persistency to your application just by running the Mirror Service, without touching the real-time portion of your application in either configuration or code. This service provides fine-grained control of which object needs to be persisted. The mirror does need a backup since it does not hold any state. The actual state of the latest committed database transaction stored within the primary and the backup space instances, not in the Mirror. Essentially, the Mirror acts as a dispatcher and push the changes done at the space (all primary partitions) into the Database (or any other data source) in an asynchronous reliable manner. In case of a failure of the Mirror, it will be restarted automatically and the primary instances will playback the un-committed transactions while the Mirror was down. The Mirror PU (like any deployed service) is mobile. It can run on any machine running a GSC, so the GSM will pick one of the existing GSCs to provision the missing Mirror PU. If from some reason the SLA you applied forcing the Mirror PU to run on a specific machine that is unavailable (for example on a specific zone which does not have any running containers), the primary and backup will hold the transaction data within their redo log queue in memory. In some point they will store it on file until the Mirror machine will be restarted.
Enabling the Mirror Service involves the following:
The above share the same Space Persistency settings but have different space settings. See the Hibernate Space Persistency for details how to use the built-in HibernateSpaceSynchronizationEndpoint. The Data-Grid Processing UnitThe cluster-config.mirror-service space settings specify the interaction between the IMDG primary spaces and the Mirror Service. The mirror="true" space element tag enables the replication mechanism from the IMDG Primary spaces to the Mirror Service. Once the mirror="true" is specified, all IMDG members will be Mirror aware and will be delegating their activities into the Mirror service. The IMDG primary instance will replicate the operations that have been logged within the primary redo log every interval-millis amount of time or interval-opers amount of operations. Both of these mechanisms are always active and the first one that is breached triggers the replication event.
The IMDG Mirror replication settings includes the following options:
The Data-Grid Space settings would look like this: <bean id="hibernateDataSource" class="org.openspaces.persistency.hibernate.DefaultHibernateSpaceDataSourceFactoryBean"> <property name="sessionFactory" ref="sessionFactory"/> </bean> <os-core:space id="space" url="/./space" schema="persistent" mirror="true" space-data-source="hibernateSpaceDataSource"> <os-core:properties> <props> <!-- Use ALL IN CACHE - Read Only from the database--> <prop key="space-config.engine.cache_policy">1</prop> <prop key="cluster-config.cache-loader.external-data-source">true</prop> <prop key="cluster-config.cache-loader.central-data-source">true</prop> <prop key="cluster-config.mirror-service.url"> jini://*/mirror-service_container/mirror-service </prop> <prop key="cluster-config.mirror-service.bulk-size">100</prop> <prop key="cluster-config.mirror-service.interval-millis">2000</prop> <prop key="cluster-config.mirror-service.interval-opers">100</prop> <prop key="cluster-config.groups.group.repl-policy.repl-original-state">true</prop> </props> </os-core:properties> </os-core:space> The above example:
You must use a Data-Grid cluster schema that includes a backup (i.e. partitioned-sync2backup) when running a Mirror Service. Without having backup, the Primary IMDG Spaces will not replicate their activities to the Mirror Service. For testing purposes, in case you don't want to start backup spaces, you can use the partitioned-sync2backup cluster schema and have 0 as the number of backups - this will still allow the primary spaces to replicate their operations to the Mirror. If you wish to change the mirror service name please refer to Async Persistency - Mirror - Advanced.
The Mirror Processing UnitThe Mirror Service is constructed using the Mirror tag. The Mirror Service itself is not a regular Space. It is dispatching the operations which have been replicated from the IMDG primary spaces to the data source (i.e. Database). The Mirror Service should be constructed as a separate processing unit, which includes only its definition. The Mirror settings includes the following options:
The following configuration shows how to configure a processing unit, to act as the Mirror Service: <os-sla:sla number-of-instances="1" /> <bean id="hibernateSpaceSynchronizationEndpoint" class="org.openspaces.persistency.hibernate.DefaultHibernateSpaceSynchronizationEndpointFactoryBean"> <property name="sessionFactory" ref="sessionFactory"/> </bean> <os-core:mirror id="mirror" url="/./mirror-service" space-sync-endpoint="hibernateSpaceSynchronizationEndpoint" operation-grouping="group-by-replication-bulk"> <os-core:source-space name="mySpace" partitions="2" backups="1"/> </os-core:mirror> The OpenSpaces mirror name space is a syntactic sugar and it is equivalent to the following configuration using regular space properties: <os-core:space id="mirror" url="/./mirror-service" schema="mirror" space-sync-endpoint="hibernateSpaceSynchronizationEndpoint"> <os-core:properties> <props> <prop key="space-config.mirror-service.cluster.name">mySpace</prop> <prop key="space-config.mirror-service.cluster.partitions">2</prop> <prop key="space-config.mirror-service.cluster.backups-per-partition">1</prop> <prop key="space-config.mirror-service.operation-grouping">group-by-replication-bulk</prop> </props> </os-core:properties> </os-core:space>
The Mirror PU ContentThe Mirror processing unit structure is shown below: -- example-mirror ------ META-INF ---------- spring -------------- pu.xml See the The Processing Unit Structure and Configuration for more information on the processing unit structure. The relevant Hibernate JAR file and its third party dependencies should be available to the mirror processing unit. The jar files should be placed in the processing unit lib directory. Mirror UndeployWhen cluster is undeployed, the mirror service must be undeployed last. This will ensure that all data is persisted properly through mirror async persistency. <!-- default value is 5 minutes --> <prop key="cluster-config.groups.group.repl-policy.async-replication.async-channel-shutdown-timeout"> 300000 </prop> Optimizing the Mirror Activity
You might want to tune the IMDG and the Mirror activity to push data into the database faster. Here are some recommendations you should consider:
<prop key="cluster-config.mirror-service.supports-partial-update">true</prop> If you are using a custom implementation of the data source you also need to implement how the partial update is persisted. Mirror MonitoringThe activity of the mirror service can be monitored using the Administration and monitoring API. This API exposes statistics on operations that were executed by the mirror and can be used to monitor the mirror throughput and health status. You may view Mirror and its replication statistics via the GigaSpaces Management Center. Move into the Space Browser tab, click the top tree Spaces icon, right click the table columns title area on the right panel, select the columns you would to view as part of the table and click OK.
Advanced Information & Operations
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |