Summary: A description of the replication schema options – asynchronous and synchronous replication, multicast and unicast.
Overview
| Tag |
Description |
Default Value |
| <replication-mode> |
Optional values: sync, async, and sync-rec-ack.
- The async mode replicates space operations to target space after the client receives the acknowledgment from the source space for the operation.
- The sync mode replicates space operations to target space before the client receives the acknowledgment from the source space for the operation. The client getting the acknowledgment for the operation only after all target spaces confirms the arrival of the replicated data.
- The sync-rec-ack (receiver's acknowledge) mode replicates space operations to target space before the client receives the acknowledgment from the source space for the operation. The client getting the acknowledgment for the operation only after the network layer confirms the arrival of the replicated data to the target machine. This mode utilizes the network bandwidth and quality and speeds up the replication time without the source space to wait for the target space to fully confirm the arrival of the replicated packet.
|
async |
| <policy-type> |
Optional values: Full Replication - all Entries in the group's spaces are replicated. Partial Replication - Entries are only replicated if their class implements the IReplicatable interface (com.j_spaces.core.client.IReplicatable; see Javadoc), a tag interface that contains no methods. This allows you to control replication at a class-based level. |
Full-replication |
| <recovery> |
Boolean value. Set to true if you want the space to recover its data from a replication partner when the GigaSpaces Server starts. |
false |
| <replicate-notify-templates> |
Boolean value. Set to true if you want to make notification templates available at the target space. |
false |
| <trigger-notify-templates> |
Boolean value. Set to true if you want to trigger matching notification templates when entries are written to the space because of replication (and thus cause remote events to be generated and sent to the notify templates listeners). If set to true, triggering occurs; if set to false, triggering does not occur. |
false |
| <repl-find-timeout> |
Timeout (in milliseconds) to wait for the lookup of a peer space.This parameter applies only when the space is searched in a Jini Lookup Service. |
10000 [ms] |
| <repl-find-report-interval> |
the interval in which the replicator thread prints a report of the failed attempts to find/locate other members. |
3000 [ms] |
| <repl-original-state> |
In order to replicate for every operation the Entry original state, not just the latest one, turn on the <repl-original-state> option. When using synchronous replication, this option is true by default. |
false |
| <communication-mode> |
Optional values: multicast or unicast |
Unicast |
| <redo-log-capacity> |
Limits the source space redo-log capacity. When a target space fails or is not accessible, its source space maintains a redo-log for all the operations that have not been replicated. If the target space is not accessible for long time or not been restarted after some time since it stopped/failed the source space might consume large amount of memory to store the operations needed to be pushed into the unavailable space. This might lead into performance problems and eventually to memory errors and source space process failure. In order to avoid such situations, you may limit the redo log size to accommodate the maximum amount of entries. Old operation will be evicted from the redo-log in FIFO manner.-1 as value does not set any limit.This option is valid only for transient spaces. |
-1 |
| <recovery-chunk-size> |
This parameter controls the chunk size that will be used when performing recovery. Tuning this parameter might speed up the recovery time after the space is restarted. |
1000 |
Asynchronous Replication Options
| Tag |
Description |
Default Value |
| <sync-on-commit> |
Boolean value. Set to true if you use transactions and you want the commit operation to be blocked until all members of the replication group receive the changes made by the transaction. The operation is not blocked if some of the transaction participants are unavailable; they simply receive the changes when they come back up. |
false |
| <sync-on-commit-timeout> |
Relevant if <sync-on-commit> is true.This is the period of time (in milliseconds) that the source space waits to get acknowledged from the target space in order to commit the replicated transaction data. |
300000 [ms] |
| <repl-chunk-size> |
Number of packets transmitted together on the network when the replication event is triggered. The maximum value you can assign for this property is <repl-interval-opers>. |
100 |
| <repl-interval-millis> |
Time (in milliseconds) to wait between replication operations. |
3000 ms |
| <repl-interval-opers> |
Number of destructive operations to wait before replicating. |
100 |
Synchronous Replication options
| Tag |
Description |
Default Value |
| <todo-queue-timeout> |
The timeout time in milliseconds that the target space waits for missing packets. When the timeout expires, replication is performed via the asynchronous replicator. |
4000 [ms] |
| <hold-txn-lock> |
When set to false, Entries under a transaction are not replicated until the transaction is finished committing.Set to true to specify that Entries under a transaction should be replicated immediately when they are written or modified, before the transaction is finished committing, so the replication is fully synchronous.This option should be used with caution, as it has a performance penalty, and in some special cases may result in deadlock. |
false |
| <multiple-opers-chunk-size> |
When performing batch operations (writeMultiple, updateMultiple, clear, takeMultiple), this element defines the number of batches you want to split the Entries into. Default is -1, meaning that by default the operation is performed on one batch. To split the Entries into several batches, define a value. For example, 100 splits the Entries into 100 batches. For more details, see Splitting Large Batches. |
-1 |
Unicast Options
| Tag |
Description |
Default Value |
| <min-work-threads> |
The synchronous replicator module allocates a thread to communicate with the target space. This thread is taken from a pool. This parameter defines the pool's minimum size. |
4 |
| <max-work-threads> |
The maximum pool size. Make this number larger than the number of target spaces. |
64 |
Multicast Options
| Tag |
Description |
Default Value |
| <adaptive> |
Boolean value. Relevant for multicast protocol only. When setting this parameter to true GigaSpaces determines in runtime whether a packet will be sent via unicast or multicast. The decision is based on the packet size and the current calculated threshold. Whenever a packet fails to be transferred via multicast, a new threshold value is set. This allows the system to adapt itself to network behavior in real-time. |
true |
| <ip-group> |
Multicast IP |
224.8.8.8 |
| <port> |
Multicast IP port |
5555 |
| <ttl> |
Used to constrain how far a multicast packet can go. Every time a router forwards the packet, it decrements the TTL field in the packet header, and if the value reaches zero, the packet is dropped. |
4 |
| <min-work-threads> |
When running in multicast mode the target space handles incoming replication packets through multiple threads taken from a dedicated thread pool. You may configure this thread's pool size. This parameter sets the pool minimum size. |
4 |
| <max-work-threads> |
This parameter sets the pool maximum size. |
64 |
 | Make sure your network and machines running GigaSpaces are configured to have multicast enabled.
See the Multicast Configuration section for details on how to enable multicast. |
Replication group definition example:
<cluster-config>
<group-name>sync_replicated_group</group-name>
<group-members>
<xsl:copy-of select="cluster-config/cluster-members/member"/>
</group-members>
<repl-policy>
<replication-mode>sync-rec-ack</replication-mode>
<policy-type>full-replication</policy-type>
<recovery>true</recovery>
<replicate-notify-templates>false</replicate-notify-templates>
<trigger-notify-templates>true</trigger-notify-templates>
<repl-find-timeout>5000</repl-find-timeout>
<repl-find-report-interval>30000</repl-find-report-interval>
<communication-mode>unicast</communication-mode>
<async-replication>
<repl-original-state>false</repl-original-state>
<sync-on-commit>false</sync-on-commit>
<sync-on-commit-timeout>300000</sync-on-commit-timeout>
<repl-chunk-size>500</repl-chunk-size>
<repl-interval-millis>3000</repl-interval-millis>
<repl-interval-opers>500</repl-interval-opers>
</async-replication>
<sync-replication>
<todo-queue-timeout>1500</todo-queue-timeout>
<unicast>
<min-work-threads>4</min-work-threads>
<max-work-threads>16</max-work-threads>
</unicast>
<multicast>
<ip-group>224.0.0.1</ip-group>
<port>28672</port>
<ttl>4</ttl>
<min-work-threads>4</min-work-threads>
<max-work-threads>16</max-work-threads>
</multicast>
</sync-replication>
</repl-policy>
</group>
</groups>
</cluster-config>
When a proxy performs a destructive operation on a space - such as, write, take, notify, or transaction commit - a replicator thread is triggered that handles all the work required to copy the operations and associated Entries into the target space.
Previous release
Add GigaSpaces wiki search to your browser search engines! 