ArangoDB | Milestone2: ArangoDB 3.3 New Data Replication

We’re pleased to announce the availability of the Milestone 2 of ArangoDB 3.3. There are a number of improvements, please consult the changelog for a complete overview of changes.

This milestone release contains our new and improved data replication engine. The replication engine is at the core of every distributed ArangoDB setup: whether it is a typical master/slave setup between multiple single servers or a full-fledged cluster. During the last month we:

• redesigned the replication protocol to be more reliable
• refactored and modernized the internal infrastructure to better support continuous asynchronous replication
• added a new global asynchronous replication API, to allow you to automatically and continuously mirror an entire ArangoDB single-instance (master) onto another one (or more)
• added support for automatic failover from a master server to one of his replica-slaves, if the master server becomes unreachable

Deprecated parameters in cluster deployment scripts

Please take especially care of checking your start script, if you perform a manual deployment of an ArangoDB cluster. Should your scripts either include the `–cluster.my-id` or `–cluster.my-local-info` parameters, please note these options are deprecated from now on.

What is global asynchronous replication and how do I use it?

Glad you asked! The new global replication API basically works very similar to the current one, documented here.

Now to give you a quick overview of what this means to you and how it can be used, we will look at some examples of the source code.

The current (old) asynchronous replication only supports synchronizing within a single arango database, if you added new databases on your master you manually had to start the replication for that database like so:

// on the master
db._createDatabse("new_database_1");
db._createDatabse("new_database_2");

// on the slave
const replication = require("@arangodb/replication");
db._createDatabse("new_database_1")
db._useDatabase("new_database_1");
replication.setupReplication(...);
db._createDatabse("new_database_2")
db._useDatabase("new_database_2");
replication.setupReplication(...);
// ...

This was very inefficient and in hindsight unnecessary. The new global replication automatically creates or drops databases on all slaves and automatically starts replicating your data:

// on the master
db._createDatabse("new_database_1");
db._createDatabse("new_database_2");

// on the slave
const replication = require("@arangodb/replication");
replication.setupReplicationGlobal(config);
// all new databases

This will now ensure that the slave instance continuously mirrors the data from the master server. In contrast to the previous solution, there will also be less load on the master server because there is now only a single replication client per server polling for changes.

Note: not all of our documentation is up to date with these latest API additions, we will adjust this over the next weeks.

Using Automatic failover for resilient single servers

One of the most asked questions is how one ensures that if the master server fails, one ensures that a slave can take over immediately. For this purpose we added the new `–replication.automatic-failover` which works in conjunction with the ArangoDB Agency to support a resilient server infrastructure.

To start a single-server and have it participate in the failover setup, you first need to start an agency and then start as many single-server instances as you want to. Once a server starts it will connect to the agency, automatically discover the master (or become master) and setup the replication; No further action required. Once a slave has started, it will automatically redirect any requests via http or velocypack to the master server to ensure consistency.

When using the ArangoDBStarter it becomes really easy to run a pair of single servers in a resilient master-slave setup. Just use `–starter.mode=resilientsingle`, in this mode a 3 machine agency is started and 2 single servers that perform asynchronous replication and failover if needed.

If you have three machines A, B & C run this on each machine:

`arangodb –starter.mode=resilientsingle –starter.join A,B,C`

The starter will decide on which 2 machines to run a single server instance. To override this decision (only valid while bootstrapping), add a `–cluster.start-single=false` to the machine where the single server instance should NOT be scheduled. For more information please check the starter documentation.

Driver Support

One of the main goals for us was to enable our customers to keep a slave server available as a hot-backup. Our aim is to simplify this as much as possible by integrating it into our official drivers.
For the beginning only the GO driver natively supports multiple ArangoDB endpoints, we will work on integrating it into our official drivers. Currently, you still need to supply a list of servers to which it can connect, future versions will take care of discovering all endpoints for you.

Download Milestone 2 of the upcoming ArangoDB 3.3