Introduction

Reasons for that can be:

• Fallback in case of a disaster in one datacenter
• Separation of concernsAnd many more.

Starting from version 3.3, ArangoDB supports datacenter to datacenterreplication, via the ArangoSync tool.

The replication done by ArangoSync is asynchronous. That means that whena client is writing data into the source datacenter, it will consider therequest finished before the data has been replicated to the other datacenter.The time needed to completely replicate changes to the other datacenter istypically in the order of seconds, but this can vary significantly depending onload, network & computer capacity.

Replication is a completely autonomous process. Once it is configured it isdesigned to run 24/7 without frequent manual intervention.This does not mean that it requires no maintenance or attention at all.As with any distributed system some attention is needed to monitor its operationand keep it secure (e.g. certificate & password rotation).

In the event of an outage of the master cluster, user intervention is requiredto either bring the master back up or to decide on making a slave cluster thenew master. There is no automatic failover as slave clusters lag behind the masterbecause of network latency etc. and resuming operation with the state of a slavecluster can therefore result in the loss of recent writes. How much can be lostlargely depends on the data rate of the master cluster and the delay betweenthe master and the slaves. Slaves will typically be behind the master by a coupleof seconds or minutes.

A message queue is used for replication. You can use either of the following:

• Kafka:Complex general purpose message queue system. Requires Java and potentiallyfine-tuning. A too small message size can cause problems with ArangoSync.Supported by all ArangoSync versions (ArangoDB Enterprise Edition v3.3.0 and above).