ArangoDB 2.8.2: Replication Enhancements

ArangoDB 2.8.2 maintenance release comes with several replication improvements and bug fixes. You can download the latest version from our download page.

What’s changed:

• the continuous replication applier will now prevent the master’s WAL logfiles from being removed if they are still needed by the applier on the slave. This should help slaves that suffered from masters garbage collection WAL logfiles which would have been needed by the slave later.

  The initial synchronization will block removal of still needed WAL logfiles on the master for 10 minutes initially, and will extend this period when further requests are made to the master. Initial synchronization hands over its handle for blocking logfile removal to the continuous replication when started via the setupReplication function. In this case, continuous replication will extend the logfile removal blocking period for the required WAL logfiles when the slave makes additional requests.

  All handles that block logfile removal will time out automatically after at most 5 minutes should a master not be contacted by the slave anymore (e.g. in case the slave’s replication is turned off, the slaves loses the connection to the master or the slave goes down).

• added all-in-one function setupReplication to synchronize data from master to slave and start the continuous replication:

  require("@arangodb/replication").setupReplication(configuration);
  

  The command will return when the initial synchronization is finished and the continuous replication has been started, or in case the initial synchronization has failed.

  If the initial synchronization is successful, the command will store the given configuration on the slave. It also configures the continuous replication to start automatically if the slave is restarted, i.e. autoStart is set to true.

  If the command is run while the slave’s replication applier is already running, it will first stop the running applier, drop its configuration and do a resynchronization of data with the master. It will then use the provided configration, overwriting any previously existing replication configuration on the slave.

  The following example demonstrates how to use the command for setting up replication for the _system database. Note that it should be run on the slave and not the master:

  db._useDatabase("_system");
    require("@arangodb/replication").setupReplication({
      endpoint: "tcp://master.domain.org:8529",
      username: "myuser",
      password: "mypasswd",
      verbose: false,
      includeSystem: false,
      incremental: true,
      autoResync: true
    });
  

• the sync and syncCollection functions now always start the data synchronization as an asynchronous server job. The call to sync or syncCollection will block until synchronization is either complete or has failed with an error. The functions will automatically poll the slave periodically for status updates.

  The main benefit is that the connection to the slave does not need to stay open permanently and is thus not affected by timeout issues. Additionally the caller does not need to query the synchronization status from the slave manually as this is now performed automatically by these functions.

• fixed undefined behavior when explaining some types of AQL traversals, fixed display of some types of traversals in AQL explain output.