Summary: Deploying common topologies: replicated (sync/async), partitioned (with/without backup), ownership cluster.
Overview
Cluster topology is defined as a relationship between individual space instances. The relationship is composed of a combination of replication, load-balancing, and failover policies. This section describes the built-in supported topologies and how to run these.
For limitations and considerations when working with a partitioned space; and details regarding multi-space operations, refer to the Partitioned Space Considerations section.
Distributed unicast-based lookup service is now supported. For more details, refer to the Space URL section.
GigaSpaces supports the following built-in topologies via cluster schema configuration files. Please consult GigaSpaces support before you create new schemas or modify these:
| Schema file |
Schema name |
Description |
More Details |
| sync_replicated-cluster-schema.xsl |
sync_replicated |
This topology replicates data in a synchronous manner between source and target spaces. Provides the highest level of coherency but impacts the client performance. |
Replicated Space Topology – Synchronous Replicated |
| async_replicated-cluster-schema.xsl |
async_replicated |
This topology replicates data in an asynchronous manner between source and target space. Data may not be coherent across the different spaces. Replication does not effect application performance. |
Replicated Space Topology – Asynchronous Replicated |
| partitioned-cluster-schema.xsl |
partitioned |
The partitioned topology provides best performance for large data sets. This topology allows to you store unlimited amount of data within the cluster by utilizing the accumulated memory size of all cluster machines. The partitioned topology routes the application's operations into difference spaces, thus storing different portions of the data in separate spaces. |
Partitioned Space Topology |
| async-repl-sync2backup-cluster-schema.xsl |
async-repl-sync2backup |
Mix between the async_replicated and the sync_replicated topologies. This topology replicates data between cluster members in an asynchronous manner and constructs backup(s) space for each cluster space where replication to backup spaces is done in a synchronous manner. This topology provides good data coherency between primary and backup spaces with minimal performance impact when replicating data to other cluster members. |
Replicated Space Topology – Asynchronous Replicated |
| primary_backup-cluster-schema.xsl |
primary_backup |
This topology constructs backup(s) spaces for a primary space. Replication from source space to backup space(s) is done in synchronous manner. |
Replicated Space Topology - Replicated Primary-Backup |
| partitioned-sync2backup-cluster-schema.xsl |
partitioned-sync2backup |
This topology constructs backup(s) for each partitioned space. Replication from each partition to its backup space is done in a synchronous manner. |
Partitioned Space Topology – Adding Backup to Each Partition |
| ownership-replicated-cluster-schema.xsl |
ownership-replicated |
To ensure data coherency for update operations you may use the ownership model. With this approach each space is responsible for performing updates on different segments of the data – i.e. there is no option to perform update operations on two copies of the same object located in different spaces at the same time – updates are always routed to the space that owns the Entry. |
Replicated Space Topology – Replicated Ownership Space |
More in this Section