This line was removed.
This word was removed. This word was added.
This line was added.
Changes (3)View Page History
In the following sections typical administrative tasks relating to the management of an OWLIM-Enterprise GraphDB-Enterprise cluster instance are covered.
h1. Remote replication
It is sometimes desirable to maintain two clusters for the purpose of disaster recovery. When the network link between two data-centres is fast and reliable, then OWLIM GraphDB instances in both data-centres can be connected up in to a single OWLIM GraphDB cluster. This is the preferred approach.
However, in situations where the network link between two data-centres is poor (slow, unreliable, high transience, etc) then a better approach for keeping the two data-centres (i.e. two OWLIM GraphDB clusters) in synch will be to use the 'remote replication'. Using this feature, a master node of one cluster can be added as a pseudo-worker not to the other cluster making a hierarchy of clusters. Master nodes for remote clusters added in this way do not take part in query answering, but do receive all updates. Also many of the time-out and synchronisation parameters for the remote cluster are relaxed in order to cope with a more troublesome network layer.
When a remote master is added to another master it will have its own set of worker nodes. In such a configuration each update handled by the remote master will be slower, because it needs to update its own worker nodes. Before adding the remote master, set the RemoteMaster attribute to true on this node. This attribute value indicates that the remote master will receive only updates, but no read requests by the controlling master. The updates will be queued and sent asynchronously from the rest of the worker nodes so that no delay in the operation of the controlling master occurs. Incremental replications are made more likely when synchronizing a remote master by increasing the tolerated distance between its the current and expected state. Deep replications will be triggered if the remote master can not be made up-to-date based on the sequence of stored updates in the transaction log. If a deep replication is necessary, a regular worker node is selected to send its contents and during the replication the controlling master will not be in writable state. However, in cases when the remote master is only few updates behind an incremental replication will occur and the controlling master will remain in a writable state and will be able to accept and process updates.