Introduction

Reasons for that can be:

And many more.

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

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

ArangoSync performs replication in a single direction only. That means that you can replicate data from cluster A to cluster B or from cluster B to cluster A, but never at the same time (one master, one or more slave clusters).
Data modified in the destination cluster will be lost!

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

Once configured, ArangoSync will replicate both structure and data of an entire cluster. This means that there is no need to make additional configuration changes when adding/removing databases or collections.
Also meta data such as users, Foxx application & jobs are automatically replicated.

A message queue developed by ArangoDB in Go and called DirectMQ is used for replication. It is tailored for DC2DC replication with efficient native networking routines.