This section describes how to configure Neo4j Fabric.
This section describes the following:
Fabric must be set on a standalone Neo4j DBMS: the settings in neo4j.conf are identified by the
The minimal requirements to setup Fabric are:
Consider a standalone Neo4j DBMS which has two databases,
Note that all databases except for the default and
system must be created using the
The simplest configuration of Fabric is:
fabric.database.name=example fabric.graph.0.uri=neo4j://localhost:7687 fabric.graph.0.database=db1 fabric.graph.1.uri=neo4j://localhost:7687 fabric.graph.1.database=db2
It comprises the Fabric database, named
example and accessible via the default URI, i.e.,
neo4j://localhost:7687, and two Fabric graphs, uniquely identified with the ID
Fabric graphs may also be identified by a name, which can be configured with the setting,
For example, if the given names are
graphA (associated to
graphB (associated to
db2), the two additional settings will be:
This way, you can access a graph by using either:
The graph name:
USE example.graphA MATCH (n) RETURN count(n) AS countNode
The graph ID:
USE example.graph(0) MATCH (n) RETURN count(n) AS countNode
In this example, all components are redundant and data is stored in a Causal Cluster. In addition to the settings described in the previous example, a setting with no single point of failure requires the use of the routing servers parameter, which specifies a list of standalone Neo4j DBMSs that expose the same Fabric database and configuration. This parameter is required in order to simulate the same connectivity that client applications use with Causal Cluster, i.e. in case of fault of one instance the client application may revert to another existing instance.
Assume that in this example, the data is stored in three databases:
The configuration of Fabric would be:
dbms.mode=SINGLE fabric.database.name=example fabric.routing.servers=server1:7687,server2:7687 fabric.graph.0.name=graphA fabric.graph.0.uri=neo4j://core1:7687,neo4j://core2:7687,neo4j://core3:7687 fabric.graph.0.database=db1 fabric.graph.1.name=graphB fabric.graph.1.uri=neo4j://core1:7687,neo4j://core2:7687,neo4j://core3:7687 fabric.graph.1.database=db2 fabric.graph.2.name=graphC fabric.graph.2.uri=neo4j://core1:7687,neo4j://core2:7687,neo4j://core3:7687 fabric.graph.2.database=db3
The configuration above must be added to the neo4j.conf file of the Neo4j DBMSs
fabric.routing.servers contains the list of available standalone Neo4j DBMSs hosting the Fabric database.
fabric.graph.<ID>.uri can contain a list of URIs, so in case the first server does not respond to the request, the connection can be established
to another server that is part of the cluster.
The URIs refer to the
neo4j:// schema so that Fabric can retrieve a routing table and can use one of the members of the cluster to connect.
The URIs in the graph settings may include routing contexts. This can be used to associate a Fabric graph with a filtered subset of Causal Cluster members, by selecting a routing policy.
As an example, assuming we have a server policy called
read_replicas defined in the configuration of the cluster we are targeting,
we might set up a Fabric graph that accesses only the read replicas of the cluster.
fabric.graph.0.name=graphA fabric.graph.0.uri=neo4j://core1:7687?policy=read_replicas fabric.graph.0.database=db1
This enables scenarios where queries executed through Fabric are explicitly offloaded to specific instances in clusters.
This section provides general information about Fabric settings and describes the ones important for creating a fabric set-up.
Please refer to
Section A.1, “Configuration settings” fort the full list of Fabric configuration options.
Fabric settings are divided in the following categories:
Name of the Fabric database. Neo4j Fabric currently supports one Fabric database in a standalone Neo4j DBMS.
A comma-separated list of Neo4j DBMSs that share the same Fabric configuration.
These DBMSs form a routing group.
A client application will route transactions through a Neo4j driver or connector to one of the members of the routing group.
A Neo4j DBMS is represented by its Bolt connector address.
URI of the Neo4j DBMS hosting the database associated to the Fabric graph.
Name of the database associated to the Fabric graph.
Name assigned to the Fabric graph. The name can be used in Fabric queries.
Any specific driver setting, i.e. any setting related to a connection to a specific Neo4j DBMS and database.This setting overrides a global driver setting.
When configuring access to a remote DBMS, please make sure that the remote is configured to advertise its address correcly.
This is done through either
Fabric uses the Neo4j Java driver to connect to and access the data stored in Neo4j databases associated to Fabric graphs. This section presents the most important parameters available to configure the driver.
Drivers settings are configured with parameters with names of the format:
A setting can be global, i.e. be valid for all the drivers used in Fabric, or it can be specific for a given connection to a Neo4j database associated to a graph. The graph-specific setting overrides the global configuration for that graph.
A drivers setting for Fabric as the following is valid for all the connections established with the Neo4j DBMSs set in Fabric:
A graph-specific connection for the database with
ID=6 will override the
fabric.driver.api setting for that database:
SSL for Fabric drivers is configured using the
Determines which driver API will be used.
Supported values are
Most driver options described in Driver Manual → Configuration have an equivalent in Fabric configuration.