ArangoDB is an open source distributed native multi-model database (Apache 2 license).
ArangoDB 3.2.16 & 3.3.12 released, the main improvements include ArangoDB’s initial support for multiple data centres. Allows you to run two ArangoDB clusters in different data centers and set up asynchronous replication from A to B.
In the event of a data center A failure, if the network connection is completely lost, you can quickly stop replication and start using cluster B in data center B as a substitute for cluster A. Later, when the disaster is over, either cluster A can be used as an asynchronous copy of cluster B, or switch back to A and continue copying data to cluster A.
What can I do?
This feature allows you to run two ArangoDB clusters in two different data centers A and B and set up asynchronous replication from A to B. This means that cluster A in data center A can be used for reading and writing operations as well as all changes, and data is copied over the network to another cluster B in data center B. The copy is asynchronous, that is, the change occurs after a brief delay, usually within a few seconds.
How do you work
In Data Center A, ArangoDB Cluster A runs, as usual, does not make any changes to its codebase and API, and provides it with a normal load. Similarly, in Data Center B, the second ArangoDB cluster B was deployed but was initially empty.
In both data centers, we deployed a Kafka messaging agent, a standard high-performance and fault-tolerant queuing system that can buffer large amounts of data in its message queue. Personal queues in Kafka are called “topics”. With Kafka, you can set up a system called “MirrorMaker” to forward a set of configurable Kafka topics from one data center to another. All of the content written to one of the topics eventually appears in the corresponding topic of Kafka in another data center. This is the primary means by which we move messages and data between data centers.
Please click here to view more info.