This section describes how to deploy a new Neo4j Causal Cluster.
This section includes:
In this section we describe how to set up a new Causal Cluster consisting of three Core instances. We then proceed to show how more Core Servers as well as Read Replicas can be added to a running cluster.
Three Cores is the minimum number of servers needed in order to form a fault-tolerant Causal Cluster. See Section 126.96.36.199, “Core Servers” for a discussion on the number of servers required in various scenarios.
Refer to Section B.1, “Set up a local Causal Cluster” for a tutorial on how to set up a Causal Cluster on a local machine.
The following configuration settings are important to consider when deploying a new Causal Cluster. See also Section 7.7, “Settings reference” for more detailed descriptions and examples.
The address or network interface this machine uses to listen for incoming messages.
Setting this value to
The address that other machines are told to connect to. In the typical case, this should be set to the fully qualified domain name or the IP address of this server.
The operating mode of a single server instance.
For Causal Clustering, there are two possible modes:
The minimum number of Core machines in the cluster at formation. A cluster will not form without the number of Cores defined by this setting, and this should in general be configured to the full and fixed amount.
The minimum number of Core instances which will exist in the consensus group.
The network addresses of an initial set of Core cluster members that are available to bootstrap this Core or Read Replica
In the default case, the initial discovery members are given as a comma-separated list of address/port pairs, and the default
port for the discovery service is
The behavior of this setting can be modified by configuring the setting
Listening on 0.0.0.0 makes the ports publicly available. Make sure you understand the security implications and strongly consider setting up encryption.
The following example shows how to set up a simple cluster with three Core servers:
In this example, we will configure three Core Servers named
We have already installed Neo4j Enterprise Edition on all three servers.
We configure them by preparing neo4j.conf on each server.
Note that they are all identical, except for the configuration of
neo4j.conf on core01.example.com:
dbms.default_listen_address=0.0.0.0 dbms.default_advertised_address=core01.example.com dbms.mode=CORE causal_clustering.initial_discovery_members=core01.example.com:5000,core02.example.com:5000,core03.example.com:5000
neo4j.conf on core02.example.com:
dbms.default_listen_address=0.0.0.0 dbms.default_advertised_address=core02.example.com dbms.mode=CORE causal_clustering.initial_discovery_members=core01.example.com:5000,core02.example.com:5000,core03.example.com:5000
neo4j.conf on core03.example.com:
dbms.default_listen_address=0.0.0.0 dbms.default_advertised_address=core03.example.com dbms.mode=CORE causal_clustering.initial_discovery_members=core01.example.com:5000,core02.example.com:5000,core03.example.com:5000
Now we are ready to start the Neo4j servers. The startup order does not matter.
After the cluster has started, we can connect to any of the instances and run
CALL dbms.cluster.overview() to check the status of the cluster.
This will show information about each member of the cluster.
We now have a Neo4j Causal Cluster of three instances running.
The instance may appear unavailable while it is joining the cluster. If you want to follow along with the startup, you can follow the messages in neo4j.log.
Core Servers are added to an existing cluster by starting a new Neo4j instance with the appropriate configuration. The new server will join the existing cluster and become available once it has copied the data from its peers. It may take some time for the new instance to perform the copy if the existing cluster contains large amounts of data.
causal_clustering.initial_discovery_members shall be updated on all the servers in the cluster to include the new server.
In this example, we will add a Core Server,
core04.example.com, to the cluster that we created in Example 7.1, “Configure a Core-only cluster”.
We configure the following entries in neo4j.conf:
neo4j.conf on core04.example.com:
dbms.default_listen_address=0.0.0.0 dbms.default_advertised_address=core04.example.com dbms.mode=CORE causal_clustering.minimum_core_cluster_size_at_formation=3 causal_clustering.minimum_core_cluster_size_at_runtime=3 causal_clustering.discovery_members=core01.example.com:5000,core02.example.com:5000,core03.example.com:5000,core04.example.com:5000
Note that the configuration is very similar to that of the previous servers.
In this example, the new server is not intended to be a permanent member of the cluster, thus it is not included in
Now we can start the new Core Server and let it add itself to the existing cluster.
Initial Read Replica configuration is provided similarly to Core Servers via neo4j.conf. Since Read Replicas do not participate in cluster quorum decisions, their configuration is shorter; they only need to know the addresses of some of the Core Servers which they can bind to in order to discover the cluster. They can then choose an appropriate Core Server from which to copy data.
In this example, we will add a Read Replica,
replica01.example.com, to the cluster that we created in Example 7.1, “Configure a Core-only cluster”.
We configure the following entries in neo4j.conf:
neo4j.conf on replica01.example.com:
Now we can start the new Read Replica and let it add itself to the existing cluster.