Configuration

Fabric database setup

Fabric must be set on a standalone Neo4j DBMS: the settings in neo4j.conf are identified by the fabric namespace. The minimal requirements to setup Fabric are:

A virtual database name: this is the entry point used by the client applications to access the Fabric environment.
One or more Fabric graph URI and database: this a reference of a URI and a database for each graph set in the Fabric environment.

Local development setup example

Consider a standalone Neo4j DBMS, which has two databases, db1 and db2. Note that all databases except for the default and system must be created using the CREATE DATABASE command.

Fabric is enabled by configuring:

fabric.database.name=example

This configuration enables Fabric and exposes the feature under the virtual database with the name example, which is accessible using the default URI, i.e., neo4j://localhost:7687. After connecting to the DBMS with the example database selected, you can run queries like the following:

USE db1
MATCH (n) RETURN n
 UNION
USE db2
MATCH (n) RETURN n

Figure 1. Minimal local Fabric setting in a development setup

Remote development setup example

This example consists of a setup with three standalone Neo4j DBMSs. One instance acts as the Fabric proxy, configured to enable Fabric. The other two instances contain the databases db1 and db2.

The following configuration enables Fabric on the proxy instance and allows it to access the databases in the other two instances.

fabric.database.name=example
fabric.graph.0.uri=neo4j://hostname-of-instance1:7687
fabric.graph.0.database=db1

fabric.graph.1.uri=neo4j://hostname-of-instance2:7687
fabric.graph.1.database=db2

This configuration enables Fabric and exposes the feature under the virtual database named example, which is accessible using the default URI, i.e. neo4j://localhost:7687. The Fabric graphs are uniquely identified by their IDs, 0 and 1.

After connecting to the DBMS with the selected database set to "example", you can run queries like the following:

USE example.graph(0)
MATCH (n) RETURN n
  UNION
USE example.graph(1)
MATCH (n) RETURN n

Figure 2. Minimal remote Fabric setting in a development setup

Naming graphs

Graphs can be identified by their ID or by a name. A graph can be named by adding an extra configuration setting, fabric.graph.<ID>.name.

For example, if the given names are graphA (associated to db1) and graphB (associated to db2), the two additional settings will be:

fabric.graph.0.name=graphA
fabric.graph.1.name=graphB

Giving names to graphs means we can refer to them by name in queries:

USE example.graphA
MATCH (n) RETURN n
 UNION
USE example.graphB
MATCH (n) RETURN n

Cluster setup with no single point of failure example

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: db1, db2 and db3. 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 server1 and server2. The parameter fabric.routing.servers contains the list of available standalone Neo4j DBMSs hosting the Fabric database. The parameter 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.

Figure 3. Fabric setting with Causal Cluster and no single point of failure

Cluster routing context

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.

Authentication and authorization

Credentials

Connections between the Fabric database and the Neo4j DBMSs hosting the data are created using the same credentials that are supplied in the client connection to the Fabric database. It is recommended to maintain a set of user credentials on all the Neo4j DBMSs; if required, a subset of credentials may be set for local access on the remote DBMSs.

User and role administration

User and role administration actions are not automatically propagated to the Fabric environment, therefore security settings must be executed on any DBMS that is part of Fabric.

Privileges on the Fabric database

In order to use all Fabric features, users of Fabric databases need ACCESS and READ privileges.

Important settings

This section provides general information about Fabric settings and describes the ones important for creating a fabric set-up. Please refer to Configuration settings fort the full list of Fabric configuration options.

Fabric settings are divided in the following categories:

System Settings: DBMS-level settings.
Graph Settings: definition and configuration of Fabric graphs.
Drivers Settings: configuration of drivers used to access Neo4j DBMSs and databases associated to Fabric graphs.

System settings

Table 1. Fabric system settings
Parameter	Description
`fabric.database.name`	Name of the Fabric database. Neo4j Fabric currently supports one Fabric database in a standalone Neo4j DBMS.
`fabric.routing.servers`	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. Example: `fabric.routing.servers=server1:7687.`

Graph settings

The <ID> in the following settings is the integer associated to each Fabric graph.

Table 2. Fabric graph settings
Parameter	Description
`fabric.graph.<ID>.uri`	URI of the Neo4j DBMS hosting the database associated to the Fabric graph. Example: `neo4j://somewhere:7687`
`fabric.graph.<ID>.database`	Name of the database associated to the Fabric graph.
`fabric.graph.<ID>.name`	Name assigned to the Fabric graph. The name can be used in Fabric queries.
`fabric.graph.<ID>.driver.*`	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 dbms.default_advertised_address or dbms.connector.bolt.advertised_address. Fabric reads the routing table from the remote DBMS and then connects back using an appropriate entry in that table.

Drivers settings

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:

fabric.driver.<suffix>

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.

Example 1. Global drivers setting versus graph-specific drivers setting

A drivers setting for Fabric as the following is valid for all the connections established with the Neo4j DBMSs set in Fabric:

fabric.driver.api=RX

A graph-specific connection for the database with ID=6 will override the fabric.driver.api setting for that database:

fabric.graph.6.driver.api=ASYNC

Table 3. Fabric drivers setting suffixes
Parameter suffix	Explanation
`ssl_enabled`	SSL for Fabric drivers is configured using the `fabric` SSL policy. This setting can be used to instruct the driver not to use SSL even though the `fabric` SSL policy is configured. The driver will use SSL if the `fabric` SSL policy is configured, and this setting is set to `true`. This parameter can only be used in `fabric.graph.<graph ID>.driver.ssl_enabled` and not `fabric.driver.ssl_enabled`.
`api`	Determines which driver API will be used. Supported values are `RX` and `ASYNC`.

Most driver options described in Driver Manual → Configuration have an equivalent in Fabric configuration.