6.4. Error handling

This section describes how to manage errors that you may encounter while managing databases.

When running the database management queries described in Section 6.3, “Queries”, such as CREATE DATABASE, it is possible that you will encounter errors.

6.4.1. Observing errors

Because database management operations are performed asynchronously, these errors may not returned immediately upon query execution. Instead, you must monitor the output of SHOW DATABASE; particularly the error and currentStatus columns:

Example 6.10. Fail to create a database

neo4j@system> CREATE DATABASE foo;

0 rows available after 108 ms, consumed after another 0 ms

neo4j@system> SHOW DATABASE foo;

+------------------------------------------------------------------------------------------------------------------+
| name   | address          | role         | requestedStatus | currentStatus | error                     | default |
+------------------------------------------------------------------------------------------------------------------+
| "foo"  | "localhost:7687" | "standalone" | "online"        | "dirty"       | "File system permissions" | FALSE   |
+------------------------------------------------------------------------------------------------------------------+

1 rows available after 4 ms, consumed after another 1 ms

6.4.2. Database states

A database management operation may fail for a number of reasons. For example, if the file system instance has incorrect permissions, or Neo4j itself is misconfigured. As a result, the contents of the error column in the SHOW DATABASE query results may vary significantly.

However, databases may only be in one of a select number of states:

Current state	Description
`initial`	The database has not yet been created.
`online`	The database is running.
`offline`	The database is not running.
`store copying`	The database is currently being updated from another instance of Neo4j.
`dropped`	The database has been deleted.
`dirty`	The databases underlying store files may be invalid.
`unknown`	This instance of Neo4j doesn’t know the state of this database.

Most often, when a database management operation fails, Neo4j will attempt to transition the database in question to the offline state. If the system is certain that no store files have yet been created, it will transition the database to initial instead. Similarly, if the system suspects that the store files underlying a database may be invalid (incomplete, partially deleted or corrupt) then it will transition a database to dirty.

Whilst dropped is a valid database state, it is only transiently observable, as database records are removed from SHOW DATABASE results once the DROP operation is complete.

6.4.3. Retrying failed operations

Database management operations may be safely retried in the event of failure. However, please note that these retries are not guaranteed to succeed, and errors may persist through several attempts.

Example 6.11. Retry starting a database

neo4j@system> STARE DATABASE foo;

0 rows available after 108 ms, consumed after another 0 ms

neo4j@system> SHOW DATABASE foo;

+-------------------------------------------------------------------------------------------------------------+
| name   | address          | role         | requestedStatus | currentStatus | error                | default |
+-------------------------------------------------------------------------------------------------------------+
| "foo"  | "localhost:7687" | "standalone" | "online"        | "offline"     | "Some error message" | FALSE   |
+-------------------------------------------------------------------------------------------------------------+

1 rows available after 4 ms, consumed after another 1 ms

Given the error message, an operator takes action on the Neo4j instance to address the underlying issue, then runs the following:

neo4j@system> STARE DATABASE foo;

0 rows available after 108 ms, consumed after another 0 ms

neo4j@system> SHOW DATABASE foo;

+------------------------------------------------------------------------------------------------+
| name     | address          | role         | requestedStatus | currentStatus | error | default |
+------------------------------------------------------------------------------------------------+
| "foo"    | "localhost:7687" | "standalone" | "online"        | "online"      | ""    | FALSE   |
+------------------------------------------------------------------------------------------------+

1 rows available after 4 ms, consumed after another 1 ms

If repeated retries of a command have no effect, or if a database is in a dirty state, then an operator may drop and recreate database, as detailed in Cypher manual → Administration.

When running DROP DATABASE as part of an error handling operation, an operator may wish to include the optional DUMP DATA keywords. This will cause the drop operation to produce a database dump which can be examined or potentially repaired.