Summary: This section describes how to configure the replication granularity and what are the trade-offs of the various options.
Replication GranularityBy default, all data and operations are replicated to all target spaces that belong to the same replication group (symmetrical replication). You can define replication granularity to start at the space level and end up at the space object level. Below are the different replication granularity options:
Replication Groups and Replication PolicyThere can be several replication groups in a cluster. However, each space can belong to one group only. The replication group determines the replication policy, which has the following main attributes:
Replication Transmission MatrixWhen a replication group is defined, by default, each member of the group replicates all changes to all other members. For example, consider a replication group of four members: SP1, SP2, SP3 and SP4. Below is the replication diagram: Sometimes a finer replication definition is needed - some spaces do not need to replicate all operations and data to other spaces. For example, assume that SP1 is an agency, connected to the agent computers SP2, SP3, and SP4. SP1 replicates and receives replications from SP2, SP3 and SP4, but SP2, SP3 and SP4 do not replicate data and operations between them. To provide this functionality, define a transmission matrix over the replication group. For each pair (source and target space) define the following:
By using the transmission matrix, you can improve performance and reduce communication overheads. Controlling Replication at the Operation LevelWhen using a replicated topology, you can instruct the primary space (source) to replicate only specific operations into the backup (replica) space. This means that you can actually "switch off" replication activity for certain operations.
GigaSpaces allows you to control replication at the operation level without implementing any replication filter. This is done by adding the <cluster-config.groups.group.repl-policy.permitted-operations> tag to your space cluster configuration. When using the cluster-config.groups.group.repl-policy.permitted-operations, specify a comma-separated list of the operations you want to be replicated to all backup (replica) spaces. Here are the available operations (in the form they should appear with the permitted-operations parameter):
For example: <os-core:space id="space" url="/./mySpace" > <os-core:properties> <props> <prop key="cluster-config.groups.group.repl-policy.permitted-operations">write, extend_lease, lease_expiration, notify</prop> </props> </os-core:properties> </os-core:space> In the example above, the take and update operations are not replicated to all spaces, while the write, extend_lease, expire_lease, and notify_registration operations are replicated to all spaces.
You can also specify that a certain operation be replicated in a distributed manner. See the following section. Distributed ReplicationIn GigaSpaces, replicated operations are usually performed first on the primary space, and only then passed to the rest of the members - this ensures consistency. Distributed replication allows you to define that an operation is performed on all replicated spaces at once. A typical use-case of this feature is with the take (clear) operation. Usually, the take operation is performed first on the primary space, then a list of UIDs is passed to the replica spaces, and the objects are taken from these. When working with large amounts of objects (hundreds of thousands, or millions), there might be a need for the replication to be faster. With distributed replication, the objects are taken from all the replicated spaces at once.
To enable distributed replication, exclude the operation you want to perform from the permitted-operations list, and enable broadcast mode (using <broadcast-condition>unconditional</broadcast-condition>) - see below. For example, if you want to perform the take operation in a distributed manner, configure the following: <os-core:space id="space" url="/./mySpace" > <os-core:properties> <props> <prop key="cluster-config.groups.group.repl-policy.permitted-operations">write, notify</prop> <prop key="cluster-config.groups.group.load-bal-policy.take.policy-type">hash-based</prop> <prop key="cluster-config.groups.group.load-bal-policy.take.broadcast-condition">unconditional</prop> </props> </os-core:properties> </os-core:space>
Replication FiltersYou can call your own business logic whenever the data is replicated. For example, you can modify the space objects data, compress/decompress, or block specific operations and space objects from being replicated to other spaces. Your business logic is called whenever the replication packet leaves the source space (output event), and arrives at the target space (input event). Replicating the Original StateWhenever you run in asynchronous replication mode and perform write and update operations, the target space might get the latest state of the space object, both for the write and the update operations. In order to replicate the space object's original state with every operation, not just the latest one, turn on the cluster-config.groups.group.repl-policy.repl-original-state option. When this option is set to true, the replication mechanism maintains for every space object, its full state, together with the operation. For example, if a space object has been written to the space and updated several times within a specific replication batch, then the replication mechanism replicates the operations in their correct order, together with the space object's original state for each operation.
When this option is set to false, the replication mechanism replicates the latest state of the space object to the target space. For example, if a space object has been written to the space and updated several times within a specific replication batch, the replication mechanism replicates the operations in their correct order. However, the replication mechanism still uses the space object with its latest state for all operations.
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |