Friday, 05 June 2020
Infinispan introduced Cross Site Replication functionality in version 5.2 and Infinispan 7 extended it to support state transfer. With an increase of popularity, Infinispan 11 brings two major improvements to Cross Site Replication. Let’s take a look at them.
Infinispan uses JGroups' RELAY2 protocol to enable inter-site communication. Each site has Site Masters: these are nodes with special roles, and are responsible for the communication between sites.
RELAY2 can use more than one Site Master per site allowing load balancing of the inter-site requests. The new algorithm is now able to take advantage of multiple Site Masters.
max_site_masters configures the number of Site Masters, and it defaults to 1. To take advantage of the new algorithm, increase the number of Site Masters in RELAY2 configuration by changing
max_site_masters to a value higher than 1. A number greater than the number of nodes can be used, and it enables the Site Master role in all nodes.
<relay.RELAY2 site="<LOCAL_SITE_NAME>" max_site_masters="<PUT_VALUE_HERE>"/>
More information about RELAY2 is available in JGroups' Manual.
Infinispan is able to detect conflicts in asynchronous mode by taking advantage of vector clocks. A conflict happens when 2 or more sites update the same key at the same time. Let’s look at an example between 2 sites (LON and NYC):
LON NYC k1=(n/a) 0,0 0,0 k1=2 1,0 --> 1,0 k1=2 k1=3 1,1 <-- 1,1 k1=3 k1=5 2,1 1,2 k1=8 --> 2,1 (conflict) (conflict) 1,2 <-- k1=5 2,1 <-> 2,1 k1=5
k1=2, with vector clock
1,0, and replicates it to NYC.
k1=3, with vector clock
1,1, and replicates it to LON.
However if LON puts
2,1), and NYC puts
k1=8in NYC (with vector clock
1,2) at the same time, Infinispan detects the conflict since none of the vector clocks are greater than the other.
Infinispan resolves the conflicts by comparing using the site names in lexicographical order. The site’s name lower in lexicographical order takes priority. In the example above, both LON and NYC end up with
k1=5 since LON < NYC.
You can choose the priority by prepending a number to the site name. For example, if you want updates from NYC to take priority over LON updates, you can prepend a number to the site name, example: 1NYC, 2LON and so on.
For more information check the Infinispan Documentation.
Tags: xsite cross site replication
Thursday, 23 February 2017
We’ve just released Infinispan Node.js Client version 0.4.0 which comes with encrypted client connectivity via SSL/TLS (with optional TLS/SNI support), as well as cross-site client failover.
Thanks to the encryption integration, Node.js Hot Rod clients can talk to Hot Rod servers via an encrypted channel, allowing trusted client and/or authenticated clients to connect. Check the documentation for information on how to enable encryption in Node.js Hot Rod client.
Also, we’ve added the possibility for the client to connect to multiple clusters. Normally, the client is connected to a single cluster, but if all nodes fail to respond, the client can failover to a different cluster, as long as one or more initial addresses have been provided. On top of that, clients can manually switch clusters using switchToCluster and switchToDefaultCluster APIs. Check documentation for more info.
On top of that, we’ve applied several bug fixes that further tighten the inner workings of the Node.js client.
Wednesday, 19 September 2012
Besides other enhancements and fixes, this release brings the first implementation of the cross-site replication functionality in Infinispan. In other words, you can now use Infinispan for backing up your data across geographically distributed sites or migrate your data where your users are (follow the sun). More about the x-site replication functionality here. You can download the distribution or the maven artifact. If you have any questions please check our forums, our mailing lists or ping us directly on IRC!
Tags: xsite cross site replication