Summary: This page explains how to establish data synchronization between multiple sites (spaces), usually used over the WAN.
OverviewMultiple site replication is the ability to replicate state between different deployed spaces, where each space can be also physically located in a different geographical location (also termed a different deployment site). Multiple site replication is a very common deployment topology in the following scenarios:
WAN Gateway FeaturesThe GigaSpaces WAN Gateway features the following:
Supported ToplogiesThis page will demonstrate two sample multi-site replication topologies. These are not the only supported topologies. In fact, the permutations of topologies are quite extensive, and we've chosen to demonstrate two of the more common topologies which can also serve as a basis for other topologies as required by the user:
For both of the above topologies, replication is done in in a similar way: Each space is replicating the relevant data to its target space(s) via a local gateway which routes the data to the gateway of the target space(s) and from there to the target space. The data is being replicated asynchronously in a reliable mode, which means that even if a primary space instance fails on the source site, the backup space instance which replaces it will immediately take control and replicate the missing data along with new data that has been generated on the newly elected primary space instance. This is very similar to the Mirror Service replication scheme. The gateway is discussed in full below. Replication may use Hub & Spoke, Ring, Hierarchical or Pass-Through architecture: Configuring a Space With Gateway TargetsA replication from one space to the another is basically a replication from a space to a target gateway. The source space is decoupled from the target space. Instead, it is configured to replicate to target space's local gateway, the local gateway is in charge of dispatching the incoming replication packets to the relevant target space. Each space needs to be made aware of the target gateways to which it replicates the data, by specifying the target gateways in the source space configuration. From the space's perspective, a replication from one space to a target gateway is like any other replication channel (e.g mirror, backup...) and the backlog and confirmation state of the replication channel to the target gateway is kept in the source space. As a result, the gateway is stateless as far as holding the replication state is concerned, and only the source space is in charge of the replication progress and state. Each gateway has a unique logical name which usually corresponds to physical site name (e.g. "London" or "New York"). This name is used by remote spaces that are replicating to this space via its local gateway. The following snippet shows how to configure a space that resides in New York to replicate to two other spaces, one in London and one in Hong Kong: <os-core:space id="space" url="/./myNYSpace" gateway-targets="gatewayTargets"/> <os-gateway:targets id="gatewayTargets" local-gateway-name="NEWYORK"> <os-gateway:target name="LONDON"/> <os-gateway:target name="HONGKONG"/> </os-gateway:targets> Each of replication channel to the gateways can be configured with more parameters, such parameters can applied to all gateways or specifically per gateway, for example: <os-core:space id="space" url="/./myNYSpace" gateway-targets="gatewayTargets"/> <os-gateway:targets id="gatewayTargets" local-gateway-name="NEWYORK" bulk-size="1000" max-redo-log-capacity="1000000"> <os-gateway:target name="LONDON" /> <os-gateway:target name="HONGKONG" bulk-size="100"/> </os-gateway:targets> Here we have specified a global bulk size of 1000 but have specifically overridden it in the replication channel to Hong Kong with 100, and have a global maximum redo log capacity for both targets of 1000000.
Configuring and Deploying the GatewayA gateway needs to be deployed locally as a processing unit in each site, and is composed of two different components: The delegator and the sink. The delegator is in charge of delegating outgoing replication from the local site to a remote gateway and the sink is in charge of dispatching incoming replication from remote sites into the local space. Gateway LookupThe different gateway components needs to locate each other across the different sites, for example, a delegator needs to locate the sink of the target gateway to which is delegates the replication. This lookup is done by using dedicated lookup services that the gateways are using to register and locate each other. Since this lookup process is usually done across the WAN, the most reasonable way of locating the lookup services is using unicast (multicast is also supported). With the following example we will demonstrate a unicast lookup discovery. Gateway Basic ConfigurationFollowing the above example, here we demonstrate how to configure the local gateway processing unit in New York, which needs to send replication to London and Hong Kong and also receive replication from these two sites. <os-gateway:delegator id="delegator" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="LONDON"/> <os-gateway:delegation target="HONGKONG"/> </os-gateway:delegations> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace"> <os-gateway:sources> <os-gateway:source name="LONDON" /> <os-gateway:source name="HONGKONG" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> <os-gateway:lookup gateway-name="HONGKONG" host="hk-gateway-host-machine" discovery-port="10003" communication-port="9000" /> </os-gateway:lookups> <!--The above ports and host names are randomly selected and have no meaning, all sites could designate the same ports as well--> In the above example we see that both the sink and delegator needs a reference to the gateway lookup configuration, and that's because both components are using this configuration to locate the relevant component or to register themselves. They use their local gateway name to identify themselves to the lookup configuration, where they should be registered and where they should look for their targets. The delegator and sink components are actually isolated and can even be deployed in separate processing units but the most simple deployment would be to bundle theses two together. However, in some cases you might want to separate this into two or more machines due to system loads or other reasons.
Gateway and the Mirror ServiceA gateway and a Mirror Service are two different components which can co-exist together without any effect on each other. A gateway is just another reliable asynchronous target. Due to this fact, we will not discuss or demonstrate mirror service along side with a gateway because they do not contradict each other or require any special configuration when used in the same space cluster. Gateway and Distributed TransactionsBy default the gateway will preserve distributed transactions atomicity (distributed transactions consolidation), this can be disabled by adding the following property to the space configuration: <os-core:space id="space" url="/./localSpace" gateway-targets="gatewayTargets"> <os-core:properties> <props> <prop key="cluster-config.groups.group.repl-policy.processing-type"> global-order </prop> </props> </os-core:properties> </os-core:space> Distributed transaction consolidation is done by waiting for all the transaction participants data before processing is done by the Sink component. It is possible to specify the behavior when processing is split to individual participants upon consolidation failure (timeout or other reasons), the unconsolidated transaction can be either aborted or committed. Please note that while waiting for the pieces of a distributed transaction to arrive at the sink, replication isn't waiting but keeping the data flow and preventing from conflicts to happen. The following example demonstrates how to set the timeout for waiting for distributed transaction data to arrive. It is also possible to set the amount of new operations to perform before processing data individually for each participant <os-gateway:sink id="sink" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace"> <os-gateway:sources> <os-gateway:source name="LONDON" /> <os-gateway:source name="HONGKONG" /> </os-gateway:sources> <os-gateway:tx-support dist-tx-wait-timeout-millis="10000" dist-tx-wait-for-opers="20" dist-tx-consolidation-failure-action="commit"/> <!--or "abort"--> </os-gateway:sink> Distributed transaction participants data will be processed individually if 10 seconds have passed and not all of the participants data has arrived or if 20 new operations were executed after the distributed transaction.
Master-Slave TopologyWith this architecture, we have a master-slave topology where all data is being manipulated in one site, and two other sites are reading the data but not updating it. In other words, the "other sites" - the slaves - should not replicate data to the other gateways. In this case, New York's site will be the active site while London and Hong Kong will be the passive sites. As explained before, being passive does not necessarily means no work is done in these sites. However, in terms of replication over the WAN, these sites should not replicate to the other sites and usually should not alter data replicated from other sites because it may cause conflicts. Like all GigaSpaces Processing Units, the configuration details of each of the above components is placed in a pu.xml file. Here are the contents of the files for each of the components:
New York Space
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-core:space id="space" url="/./myNYSpace" gateway-targets="gatewayTargets"/> <os-gateway:targets id="gatewayTargets" local-gateway-name="NEWYORK"> <os-gateway:target name="LONDON"/> <os-gateway:target name="HONGKONG"/> </os-gateway:targets> </beans> New York Gateway <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-gateway:delegator id="delegator" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="LONDON"/> <os-gateway:delegation target="HONGKONG"/> </os-gateway:delegations> </os-gateway:delegator> <!--No sink needed as this site is not receiving replication from any gateway--> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> <os-gateway:lookup gateway-name="HONGKONG" host="hk-gateway-host-machine" discovery-port="10003" communication-port="9000" /> </os-gateway:lookups> <!-- The above ports and host names are randomly selected and has no meaning, all sites could designate the same ports as well--> </beans> London Space <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-core:space id="space" url="/./myLondonSpace"/> <!-- No gateway targets needed as this space is not replicating to any gateway--> </beans> London Gateway <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <!--No delegator needed as this site is not replicating to any gateway--> <os-gateway:sink id="sink" local-gateway-name="LONDON" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myLondonSpace"> <os-gateway:sources> <os-gateway:source name="NEWYORK" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> </os-gateway:lookups> <!-- Only the lookup parameters of this site is needed since the sink will only register itself in the lookup service and no delegator exists so there is no need to find a remote gateway --> </beans> Hong Kong Space <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-core:space id="space" url="/./myHKSpace"/> <!-- No gateway targets needed as this space is not replicating to any gateway--> </beans> Hong Kong Gateway <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <!-- No delegator needed as this site is not replicating to any gateway--> <os-gateway:sink id="sink" local-gateway-name="HONGKONG" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myHKSpace"> <os-gateway:sources> <os-gateway:source name="NEWYORK" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="HONGKONG" host="HK-gateway-host-machine" discovery-port="10003" communication-port="9000" /> </os-gateway:lookups> <!-- Only the lookup parameters of this site is needed since the sink will only register itself in the lookup service and no delegator exists so there is no need to find a remote gateway --> </beans> Multi-Master TopologyWith this architecture, we will have a multi-master topology where data is being generated and manipulated in all sites. We will demonstrate this using two sites but any number of sites is supported in the same manner. In a master-slave topology, each site should try to modify different subsets of the data as much as possible because many conflicts can occur if multiple sites are changing the same space entries at the same time. Such conflict can be resolved using a conflict resolver which will be discussed fully at Multi-Site Conflict Resolution. With the example below we will have only New York and London as the two active sites. Here are the contents of the files for each of the components:
New York Space
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-core:space id="space" url="/./myNYSpace" gateway-targets="gatewayTargets"/> <os-gateway:targets id="gatewayTargets" local-gateway-name="NEWYORK"> <os-gateway:target name="LONDON"/> </os-gateway:targets> </beans> New York Gateway <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-gateway:delegator id="delegator" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="LONDON"/> </os-gateway:delegations> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace"> <os-gateway:sources> <os-gateway:source name="LONDON" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> </os-gateway:lookups> <!--The above ports and host names are randomly selected and have no meaning, all sites could designate the same ports as well--> </beans> London Space <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-core:space id="space" url="/./myLondonSpace" gateway-targets="gatewayTargets"/> <os-gateway:targets id="gatewayTargets" local-gateway-name="LONDON"> <os-gateway:target name="NEWYORK"/> </os-gateway:targets> </beans> London Gateway <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <os-gateway:delegator id="delegator" local-gateway-name="LONDON" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="NEWYORK"/> </os-gateway:delegations> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="LONDON" gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myLondonSpace"> <os-gateway:sources> <os-gateway:source name="NEWYORK" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> </os-gateway:lookups> <!--The above ports and host names are randomly selected and have no meaning, all sites could designate the same ports as well--> </beans> Symmetric Gateway Config In this example, the gateway pu.xml is quite symmetric, the only difference is the local gateway name and the target gateway name. In such cases, it may be more convenient to create a single gateway pu.xml and use place holders to override the relevant properties at deploy time by injecting values for these properties: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-core="http://www.openspaces.org/schema/core" xmlns:os-events="http://www.openspaces.org/schema/events" xmlns:os-remoting="http://www.openspaces.org/schema/remoting" xmlns:os-sla="http://www.openspaces.org/schema/sla" xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.openspaces.org/schema/core http://www.openspaces.org/schema/9.5/core/openspaces-core.xsd http://www.openspaces.org/schema/events http://www.openspaces.org/schema/9.5/events/openspaces-events.xsd http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/9.5/remoting/openspaces-remoting.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/9.5/sla/openspaces-sla.xsd http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/9.5/core/gateway/openspaces-gateway.xsd"> <bean id="propertiesConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/> <os-gateway:delegator id="delegator" local-gateway-name="${localGatewayName}" gateway-lookups="gatewayLookups"> <os-gateway:delegations> <os-gateway:delegation target="NEWYORK"/> <os-gateway:delegation target="LONDON"/> </os-gateway:delegations> </os-gateway:delegator> <os-gateway:sink id="sink" local-gateway-name="${localGatewayName}" gateway-lookups="gatewayLookups" local-space-url="${localSpaceUrl}"> <os-gateway:sources> <os-gateway:source name="NEWYORK" /> <os-gateway:source name="LONDON" /> </os-gateway:sources> </os-gateway:sink> <os-gateway:lookups id="gatewayLookups"> <os-gateway:lookup gateway-name="NEWYORK" host="ny-gateway-host-machine" discovery-port="10001" communication-port="7000" /> <os-gateway:lookup gateway-name="LONDON" host="london-gateway-host-machine" discovery-port="10002" communication-port="8000" /> </os-gateway:lookups> <!--The above ports and host names are randomly selected and have no meaning, all sites could designate the same ports as well--> </beans> In the above we have configured both LONDON and NEWYORK at the sources of the sink and as delegation target, the delegator and the sink will filter a gateway target and source if they match their local name. Using the above technique may simplify scenarios which are symmetric but it is not recommended when the scenarios are not symmetric as it can be unnecessarily confusing.
Filtering Replication Between GatewaysIn some cases, there can be data that should not be replicated between the sites but should still be replicated locally to the backup or a mirror service. Hence, specifying the object is not replicated does not fit. Since a replication channel to a gateway is like any other replication channel, a custom Replication Filter at the source space can be used to filter the relevant data from being sent to the target gateway. This filtering should be based on the replication target name in order to identify that the replication filter is called for the correct outgoing replication to the gateway.
Bootstrap One Site From Another SiteBootstrapping a site from another site is a process in which one site space is starting fresh and it is being populated with the data of another site space. This can be useful after a very long disconnection where the replication redo-log in the source spaces that replicates to this site was dropped due to breaching capacity limitations, and the disconnected site should start fresh. Other reasons may be an explicit planned downtime due-to some maintenance of one site which lead to a complete system bootstrap once restarted.
Changing Sites Topology During RuntimeThe topology might change during runtime, for instance a new site can be added and the existing sites should be familiar with it and start replicating to it and receive replication from it. On the other hand a site can be removed and the existing should stop holding replication backlog for it and drop it from their list of gateway targets.
Read MoreThe following pages in this section provide more details on the Multi-Site Replication module:
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |