New server rolling upgrade of a cluster

Important

It is recommended to read the Introduction and Changes from Neo4j 5 to 2025.x before continuing.

In the 2025.01 release, discovery service v1 is removed. Therefore, you must transition to v2 before upgrading to Neo4j 2025.01. For more details, please refer to the Operations Manual → Moving from discovery service v1 to v2. Additionally, the dbms.cluster.discovery.version setting is ignored in Neo4j 2025.01 and later, and dbms.cluster.discovery.v2.endpoints is deprecated in favor of dbms.cluster.endpoints. Therefore, it is recommended to remove dbms.cluster.discovery.version and replace dbms.cluster.discovery.v2.endpoints with dbms.cluster.endpoints in the neo4j.conf file of each server when replacing the binaries. Otherwise, you can do the at a later time.

This is an example of how to do a rolling upgrade without reducing fault tolerance, by adding servers before removing old ones. This approach is suitable for deployments that use replaceable cloud or container resources.

Before you begin

Ensure that the databases cannot be stopped, created, or dropped during the rolling upgrade by using the following command:
```
DENY STOP ON DATABASE * TO PUBLIC
DENY DATABASE MANAGEMENT ON DBMS TO PUBLIC
```
Verify that all databases are online. See Operations Manual → Start databases for details.

Upgrade steps (to be repeated for each server)

Perform these steps in full for each server, before moving on to the next server. You must ensure that the cluster returns to a stable state before moving on to the next.

Check the cluster is healthy.
1. Before replacing the server, ensure that the cluster is in a healthy state. Use the following query to check servers are hosting all their assigned databases. The query should return no results:
  SHOW SERVERS YIELD name, hosting, requestedHosting, serverId WHERE requestedHosting <> hosting
  Composite databases appear in both hosting and requestedHosting fields.
2. Use the following query to check all databases are in their expected state. The query should return no results:
  SHOW DATABASES YIELD name, address, currentStatus, requestedStatus, statusMessage WHERE currentStatus <> requestedStatus RETURN name, address, currentStatus, requestedStatus, statusMessage
Create the new server.
(Recommended when moving from Neo4j 5.26) Remove dbms.cluster.discovery.version and replace dbms.cluster.discovery.v2.endpoints with dbms.cluster.endpoints in the neo4j.conf file.
Add the new server to the cluster:
1. Start the new server and wait for it to be visible to the cluster.
2. Use SHOW SERVERS to see the new server, it should have the status Free. Make a note of the new server’s ID.
3. Add the server to the DBMS by running ENABLE SERVER [new-server-id]. This allows the DBMS to use the server to host databases.
Prepare a server for removal:
1. Run SHOW SERVERS to retrieve the ID of one of the old servers. The server must be Available.
2. Move all databases off the old server by running:
  DEALLOCATE DATABASES FROM SERVER [old-server-id]
3. Wait for all databases to be deallocated. You can use SHOW SERVER WHERE name = [old-server-id] to follow the process. Once the databases complete their move, the hosting column will contain only system and the state column of all deallicated databases will display DEALLOCATED.
4. Verify that all moved databases are online on their new host by running:
  SHOW DATABASES
Remove the old server:
1. Shut down the old server.
2. When the process stops, remove the old server by running DROP SERVER [old-server-id]. It may still appear as Dropped in SHOW SERVERS until the process stops.
(Optional) If you have installed any plugins, make sure they are compatible with the new version.

The latest APOC is available under /labs, whilst GDS, Bloom, GenAI, and NOM are available under /products. Currently, an incompatible GDS or APOC version prevents Neo4j from starting up.
(Optional) Restore the privilege of the PUBLIC role to stop databases:
```
REVOKE DENY STOP ON DATABASE * FROM PUBLIC
```
(Optional) Restore the privilege of the PUBLIC role to create and drop databases:
```
REVOKE DENY DATABASE MANAGEMENT ON DBMS FROM PUBLIC
```
(Optional) If you have started offline databases during the preparation phase for a rolling upgrade, you need to stop each of them in order to restore them to the original state.
If using the LIST discovery method after you upgrade all the servers, make sure to set dbms.cluster.endpoints to include only the new servers.

See also dbms.cluster.discovery.resolver_type.

Monitor the logs

When Neo4j restarts, it is a good idea to monitor the logs for any errors or warnings caused by the upgrade. The neo4j.log file contains information on the upgrade.