Read-replicas

Public Beta

This feature is in Public Beta for all customers of GrapheneDB deploying a Neo4j Community v5 database on a DS3 plan or higher. While in Beta we recommend to avoid using this feature for production environments and use it for evaluation purposes.

We highly appreciate any feedback that you may have. Please reach out to us if you see anything that can be improved or if you encounter any errors.

Overview

When deploying a database at GrapheneDB you get:

Always a main node. The main node is the server hosting the database that is receiving all your write requests. You can also read from it, but ideally you do it from the Replicas to save all the resources of the main node for your writes and to be able to benefit from the redundancy and availability of the Replicas.
Optionally Read-replicas. A Read-replica in GrapheneDB is one or more dedicated servers that maintain the same data as the main node by replicating the incoming write transactions.

Replication

Read-replicas replicate the main node write transactions and apply the operations to their data sets asynchronously. How much the replicas lag behind the main node will depend on your load, but we have designed this feature for a realistic under 100ms delay.

Replication provides redundancy and increases data availability. Replicas are deployed automatically in different Availability Zones, providing a level of fault tolerance against zonal outages.

Additionally if you add more than one Replica, replication can provide increased read capacity as clients can send read operations to different servers.

You can also add Replicas to your deployment for other purposes, such as disaster recovery, running expensive read requests without affecting your main node, etc.

Manage Read-replicas

To add or remove a Read-replica, please navigate to the database Overview > Manage Read-replicas view.

You can select the number of Replicas that you want to be added/removed.

After you confirm your selection an operation will start to create/remove Replicas. When a new Replica is added it gets seeded with a snapshot of the latest data of the main node.

There is no downtime involved when adding or removing Read-replicas. Your Main node and the other Replicas are not affected by this operation.

Connecting to your Read-replicas

We provide a specific Read-only endpoint for connecting to your Replicas. This endpoint is going to connect randomly to one of your Replicas. You can find the Read-only Endpoint by navigating to the Connection view in the Database area.

Use the Read endpoint only for your reads. All writes to the Read endpoint will result in an error:

Neo.DatabaseError.General.UnknownError
gdbcc.driver.cluster.Error$InvalidServerNode$: Transaction applied in a replica

Designing your connections

Please make sure to follow the instructions of the driver that you’re using to connect to your database. It’s important when designing your connection to a database with Replicas to:

Create a driver object to establish a new connection to the Main Endpoint and one driver object to the Read-only Endpoint. Driver objects are expensive to create so make sure to resuse them. They manage automatically a connection pool for you.
Create a new session for every new transaction or causally chained series of transactions. Sessions are lightweight and should be closed, as a connection pool has a limited number of sessions.

By creating a new session from the driver object against the Read-only Endpoint you’re ensuring that reads are balanced across available Replicas. Also, in case you have more than one Replica, and there is a zonal outage, you will be able to keep reading from the Replicas that are not affected, since Replicas get deployed automatically in different availability zones.