Upgrading to ArangoDB 2.8

Please read the following sections if you upgrade from a previous version toArangoDB 2.8. Please be sure that you have checked the list of changes in 2.8before upgrading.

Please note first that a database directory used with ArangoDB 2.8cannot be used with earlier versions (e.g. ArangoDB 2.7) anymore. Upgrading a database directory cannot be reverted. Thereforeplease make sure to create a full backup of your existing ArangoDBinstallation before performing an upgrade.

Database Directory Version Check and Upgrade

ArangoDB will perform a database version check at startup. When ArangoDB 2.8encounters a database created with earlier versions of ArangoDB, it will refuseto start. This is intentional.

The output will then look like this:

2015-12-04T17:11:17Z [31432] ERROR In database '_system': Database directory version (20702) is lower than current version (20800).
2015-12-04T17:11:17Z [31432] ERROR In database '_system': ----------------------------------------------------------------------
2015-12-04T17:11:17Z [31432] ERROR In database '_system': It seems like you have upgraded the ArangoDB binary.
2015-12-04T17:11:17Z [31432] ERROR In database '_system': If this is what you wanted to do, please restart with the
2015-12-04T17:11:17Z [31432] ERROR In database '_system':   --upgrade
2015-12-04T17:11:17Z [31432] ERROR In database '_system': option to upgrade the data in the database directory.
2015-12-04T17:11:17Z [31432] ERROR In database '_system': Normally you can use the control script to upgrade your database
2015-12-04T17:11:17Z [31432] ERROR In database '_system':   /etc/init.d/arangodb stop
2015-12-04T17:11:17Z [31432] ERROR In database '_system':   /etc/init.d/arangodb upgrade
2015-12-04T17:11:17Z [31432] ERROR In database '_system':   /etc/init.d/arangodb start
2015-12-04T17:11:17Z [31432] ERROR In database '_system': ----------------------------------------------------------------------
2015-12-04T17:11:17Z [31432] FATAL Database '_system' needs upgrade. Please start the server with the --upgrade option

To make ArangoDB 2.8 start with a database directory created with an earlierArangoDB version, you may need to invoke the upgrade procedure once. This canbe done by running ArangoDB from the command line and supplying the —upgradeoption.

Note: here the same database should be specified that is also specified whenarangod is started regularly. Please do not run the —upgrade command on eachindividual database subfolder (named database-<some number>).

For example, if you regularly start your ArangoDB server with

unix> arangod mydatabasefolder

then running

unix> arangod mydatabasefolder --upgrade

will perform the upgrade for the whole ArangoDB instance, including all of itsdatabases.

Starting with —upgrade will run a database version check and perform anynecessary migrations. As usual, you should create a backup of your databasedirectory before performing the upgrade.

The last line of the output should look like this:

2015-12-04T17:12:15Z [31558] INFO database upgrade passed

Please check the full output the —upgrade run. Upgrading may produce errors, which needto be fixed before ArangoDB can be used properly. If no errors are present orthey have been resolved manually, you can start ArangoDB 2.8 regularly.

Upgrading a cluster planned in the web interface

A cluster of ArangoDB instances has to be upgraded as well. Thisinvolves upgrading all ArangoDB instances in the cluster, as well asrunning the version check on the whole running cluster in the end.

We have tried to make this procedure as painless and convenient for you.We assume that you planned, launched and administrated a cluster using thegraphical front end in your browser. The upgrade procedure is then asfollows:

• First shut down your cluster using the graphical front end asusual.

• Then upgrade all dispatcher instances on all machines in yourcluster using the version check as described above and restart them.

• Now open the cluster dash board in your browser by pointing it tothe same dispatcher that you used to plan and launch the cluster in the graphical front end. In addition to the usual buttons“Relaunch”, “Edit cluster plan” and “Delete cluster plan” you willsee another button marked “Upgrade and relaunch cluster”.

• Hit this button, your cluster will be upgraded and launched andall is done for you behind the scenes. If all goes well, you willsee the usual cluster dash board after a few seconds. If there is an error, you have to inspect the log files of your clusterArangoDB instances. Please let us know if you run into problems.

There is an alternative way using the ArangoDB shell. Instead ofsteps 3. and 4. above you can launch arangosh, point it to the dispatcherthat you have used to plan and launch the cluster using the option—server.endpoint, and execute

arangosh> require("org/arangodb/cluster").Upgrade("root","");

This upgrades the cluster and launches it, exactly as with the button above in the graphical front end. You have to replace "root" witha user name and "" with a password that is valid for authenticationwith the cluster.

Upgrading Foxx apps generated by ArangoDB 2.7 and earlier

The implementation of the require function used to import modules inArangoDB and Foxx has changedin order to improve compatibility with Node.js modules.

Given an app/service with the following layout:

• manifest.json
• controllers/
  • todos.js
• models/
  • todo.js
• repositories/
  • todos.js
• node_modules/
  • models/
    • todo.jsThe file controllers/todos.js would previously contain the followingrequire calls:

var _ = require('underscore');
var joi = require('joi');
var Foxx = require('org/arangodb/foxx');
var ArangoError = require('org/arangodb').ArangoError;
var Todos = require('repositories/todos'); // <-- !
var Todo = require('models/todo'); // <-- !

The require paths repositories/todos and models/todo were previouslyresolved locally as relative to the app root.

Starting with 2.8 these paths would instead be resolved as relative tothe node_modules folder or the global ArangoDB module paths before beingresolved locally as a fallback.

In the given example layout the app would break in 2.8 because the modulename models/todo would always resolve to node_modules/models/todo.js(which previously would have been ignored) instead of the local models/todo.js.

In order to make sure the app still works in 2.8, the require calls incontrollers/todos.js would need to be adjusted to look like this:

var _ = require('underscore');
var joi = require('joi');
var Foxx = require('org/arangodb/foxx');
var ArangoError = require('org/arangodb').ArangoError;
var Todos = require('../repositories/todos'); // <-- !
var Todo = require('../models/todo'); // <-- !

Note that the old “global” style require calls may still work in 2.8 butmay break unexpectedly if modules with matching names are installed globally.