Managing servers in a clusterEnterprise Edition
In a clustered environment, server management is completely separate from database management. This section describes how to work with servers in a cluster: adding and removing them, as well as altering their metadata.
For details on server management command syntax, see Server management command syntax.
Server lifecycle
A server can exist in six different states within the DBMS:
-
Free
-
Enabled
-
Cordoned
-
Deallocating
-
Deallocated
-
Dropped
Free state
When a server is discovered by the discovery service (see Setting up a cluster → Cluster server discovery for more information), it is created in the free state. Servers in this state have a unique automatically generated ID, but are otherwise unconfigured. These free servers are not yet part of the cluster and cannot be allocated to host any databases.
|
When first discovered, a server’s name defaults to the value of its generated server ID. |
Enabled state
When you deploy a cluster for the first time, at least the minimum number of servers included in the initial deployment are automatically enabled. For details, refer to the example on how to Configure a cluster with three servers.
If you add a new server after the cluster is already running, the server is added in the Free state.
A server in the Free state needs to be explicitly enabled in order to be considered an active member of the cluster.
To transition a server into the enabled state, use the command ENABLE SERVER:
ENABLE SERVER 'serverId' [OPTIONS "{" option: value[,...] "}"]
The server’s initial name is its ID. If the server is already enabled and the command is executed with the same options, nothing is changed.
The possible options when enabling a server are:
| Option | Allowed values | Description |
|---|---|---|
modeConstraint |
|
Databases may only be hosted on the server in the mode specified by the constraint.
|
allowedDatabases |
list of database names, e.g. |
Only databases matching the specified names may be hosted on the server.
This may not be specified in combination with |
deniedDatabases |
list of database names, e.g. |
Only databases not matching the specified names may be hosted on the server.
This may not be specified in combination with |
tags |
list of server tags, e.g. |
List of server tags used for load balancing and routing policies. |
|
When a server is enabled, if no All these settings are only effective when enabling the relevant server. |
Another way to enable servers is to configure the DBMS automatically enable free servers. You can do this in one of two ways:
-
By setting
initial.dbms.automatically_enable_free_serverstotruebefore starting the deployment for the first time. -
By running the following procedure after deployment:
CALL dbms.cluster.setAutomaticallyEnableFreeServers(true);
Once enabled, the server may be allocated databases to host.
If you need to change some of the server’s values, use the ALTER SERVER command.
Cordoned state
A server in a cordoned state cannot be assigned to host any newly created databases; however, the server retains the databases it already hosts.
This state is primarily used for error handling.
To transition a server from the enabled to the cordoned state, run the dbms.cluster.cordonServer() procedure.
Keep in mind that when decreasing the number of allocations of a database, allocations on cordoned servers are removed first.
A server in the cordoned state can be transitioned to deallocating state or back to enabled.
To re-enable a server, run the ENABLE SERVER command.
In Cypher 5, you can also use the dbms.cluster.uncordonServer() procedure.
Deallocating state
A deallocating state means a server can no longer host databases. It may be that the server is no longer needed and you want to remove it from the cluster.
To transition servers to the deallocating state, run the following command:
DEALLOCATE DATABASE[S] FROM SERVER[S] 'name'[, ...]
The command reallocates all user databases hosted by the server to other servers in the cluster. This state is irreversible. Once a server is in a deallocating state, it subsequently cannot have any further databases allocated to it.
However, you can deallocate databases from a server in a reversible manner by running one of the following procedures:
For details, see Managing databases in a cluster → Deallocate databases.
Deallocated state
The deallocated state means that a server no longer hosts any databases besides the system database and can be removed from the cluster.
Additionally, deallocated servers cannot have any further databases allocated to them.
Note that there is a known situation in which a previously deallocated offline server can transiently show as deallocating when restarting, it will, however, eventually return to the deallocated state without intervention.
Dropped state
The dropped state means a server has been removed from the cluster but remains visible to the other cluster members.
Once a server is in the deallocated state and is only hosting the system database, it is safe to remove it.
Use the command DROP SERVER 'server name' to remove the server from the cluster.
However, as long as the server’s Neo4j process is running, it is still visible to the other cluster members in the dropped state. When the Neo4j process is stopped, the server finally disappears. Once dropped, a server cannot rejoin a cluster.
|
To allow the same physical hardware to rejoin the cluster, reset the Neo4j installation by either:
This process ensures a new server ID is generated when the server starts again. |
Showing servers
The Cypher command SHOW SERVERS displays all current servers running in the cluster, including servers yet to be enabled (i.e. servers in the free state) in the DBMS as well as dropped servers.
neo4j@system> SHOW SERVERS;
+------------------------------------------------------------------------------------------------------------------+
| name | address | state | health | hosting |
+------------------------------------------------------------------------------------------------------------------+
| "135ad202-5405-4d3c-9822-df39f59b823c" | "localhost:7690" | "Dropped" | "Available" | ["system"] |
| "25a7efc7-d063-44b8-bdee-f23357f89f01" | "localhost:7689" | "Enabled" | "Available" | ["system", "foo", "neo4j"] |
| "42a97acc-acf6-40c0-aff2-3993e90db1ff" | "localhost:7691" | "Free" | "Available" | ["system"] |
| "782f0ee2-5474-4250-b905-4cd8b8f586ba" | "localhost:7688" | "Enabled" | "Available" | ["system", "foo", "neo4j"] |
| "8512c9b9-d9e8-48e6-b037-b15b0004ca18" | "localhost:7687" | "Enabled" | "Available" | ["system", "foo", "neo4j"] |
+------------------------------------------------------------------------------------------------------------------+
To display all available information about the servers in the cluster, use SHOW SERVERS YIELD *:
neo4j@system> SHOW SERVERS YIELD *;
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| serverId | name | address | httpAddress | httpsAddress | state | health | hosting | requestedHosting | tags | allowedDatabases | deniedDatabases | modeConstraint | version |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| "135ad202-5405-4d3c-9822-df39f59b823c" | "135ad202-5405-4d3c-9822-df39f59b823c" | "localhost:7690" | "localhost:7477" | NULL | "Deallocating" | "Available" | ["system"] | ["system"] | [] | [] | [] | "NONE" | "5.0.0-drop09.0" |
| "25a7efc7-d063-44b8-bdee-f23357f89f01" | "25a7efc7-d063-44b8-bdee-f23357f89f01" | "localhost:7689" | "localhost:7476" | NULL | "Enabled" | "Available" | ["system", "foo", "neo4j"] | ["system", "foo", "neo4j"] | [] | [] | [] | "NONE" | "5.0.0-drop09.0" |
| "42a97acc-acf6-40c0-aff2-3993e90db1ff" | "42a97acc-acf6-40c0-aff2-3993e90db1ff" | "localhost:7691" | "localhost:7478" | NULL | "Free" | "Available" | ["system"] | [] | [] | [] | [] | "NONE" | "5.0.0-drop09.0" |
| "782f0ee2-5474-4250-b905-4cd8b8f586ba" | "782f0ee2-5474-4250-b905-4cd8b8f586ba" | "localhost:7688" | "localhost:7475" | NULL | "Enabled" | "Available" | ["system", "foo", "neo4j"] | ["system", "foo", "neo4j"] | [] | [] | [] | "NONE" | "5.0.0-drop09.0" |
| "8512c9b9-d9e8-48e6-b037-b15b0004ca18" | "8512c9b9-d9e8-48e6-b037-b15b0004ca18" | "localhost:7687" | "localhost:7474" | NULL | "Enabled" | "Available" | ["system", "foo", "neo4j"] | ["system", "foo", "neo4j"] | [] | [] | [] | "NONE" | "5.0.0-drop09.0" |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
The table of results shows information about the servers.
| Column | Description | Type | Default output | Full output |
|---|---|---|---|---|
name |
Name of the server. |
|
||
serverId |
ID of the server. |
|
||
address |
Bolt address of the server (if enabled). |
|
||
httpAddress |
HTTP address of the server (if enabled). |
|
||
httpsAddress |
HTTPS address of the server (if enabled). |
|
||
state |
Information of the state of the server. Possible values are |
|
||
health |
The availability of the server: |
|
||
hosting |
A list of databases currently hosted on the server. |
|
||
requestedHosting |
A list of databases that should be hosted on the server.
Composite databases do not currently appear in this list, though they do appear in |
|
||
tags |
Tags are user provided strings that can be used for load balancing and routing policies. |
|
||
allowedDatabases |
A list of databases allowed to be hosted on the server. |
|
||
deniedDatabases |
A list of databases not allowed to be hosted on the server. |
|
||
modeConstraint |
Constraint for the allocator to allocate only databases in this mode on the server. |
|
||
version |
Neo4j version the server is running. |
|
|
For general information about the |
Adding a server to the cluster
To add a server to a running cluster, configure it to discover other existing cluster members. There are several different ways to do this, see Cluster server discovery.
In the example below, you set dbms.cluster.discovery.resolver_type=LIST.
-
Prepare the neo4j.conf file for the new
server.07.neo4j.conf on server07.example.com:server.default_listen_address=0.0.0.0 server.default_advertised_address=server07.example.com dbms.cluster.discovery.resolver_type=LIST dbms.cluster.endpoints=server01.example.com:6000,server02.example.com:6000,server03.example.com:6000,server04.example.com:6000,server05.example.com:6000,server06.example.com:6000, server.cluster.system_database_mode=PRIMARYConfigure the
systemdatabase mode according to the server’s purpose:-
Set the mode to
PRIMARYif the server is expected to be long-term and handle high-volume workloads. -
Set the mode to
SECONDARYif the server is intended to support analytics or read-heavy workloads.Additionally, you can configure a set of initial settings to provide values for the server’s options. Those settings will be used as the default input for the
ENABLE SERVERcommand. For details, see Enabled state.Besides, you can also set the
initial.dbms.automatically_enable_free_serverstotrue, allowing the DBMS automatically enable a free server.
-
-
Once the new server is configured to discover the cluster’s members, start the Neo4j process.
-
Once started, the new server appears in the output of
SHOW SERVERSwith theFreestate. -
Copy the server’s ID from the
SHOW SERVERSoutput and enable the server.The
ENABLE SERVERcommand can take several options and it will override the initial settings if they are conflicting:neo4j@system> ENABLE SERVER '25a7efc7-d063-44b8-bdee-f23357f89f01' OPTIONS {modeConstraint:'PRIMARY', allowedDatabases:['foo'], tags:['eu','eu-west']};-
modeConstraintis used to control whether a server can only host standard databases in primary mode, only in secondary mode, or can host databases in either mode. -
allowedDatabasesanddeniedDatabasesare collections of database names that filter which databases may be hosted on a server. TheallowedDatabasesanddeniedDatabasesare mutually exclusive and if both are specified, an error is returned.allowedDatabasesanddeniedDatabasesdo not affect composite databases, they are always available everywhere. Note that starting from 2025.12, database name patterns (wildcards) are supported, and the minimum length is reduced from3to1. -
Server
tagsare used when configuring load balancing and replication policies. They cannot contain duplicates, sotags:['eu', 'eu']will return an error. Server tags also cannot contain commas. When altering server tags via Cypher, the encoding is done via UTF-8.The input for server tags is a comma-separated list that cannot have duplicates.
Neo4j .conf files use Latin1 for their encoding by default. Therefore, for server tags that need a larger character set (e.g. Chinese or Arabic), it is recommended to use Cypher to alter server tags.
The .conf files can use UTF-8 by setting the environment variable
NEO4J_CONFIG_FILE_CHARSET=utf8. This allows setting server tags with the larger character set via the config.
-
Hosting databases on added servers
Once enabled, a server does not automatically host databases unless:
-
New databases are created.
-
Existing database topologies are altered to request more hosts.
-
Another server is transitioned to the deallocating state.
-
You explicitly rebalance the databases across the cluster, possibly reallocating some databases to the newly added server(s). For more information, see Reallocate databases.
Removing a server from the cluster
Removing a server from the cluster requires two steps: deallocating, then dropping.
Deallocating databases from a server
In preparation for removing a server from the cluster, set it to not host any databases with the DEALLOCATE DATABASES FROM SERVER 'name' command.
See deallocating state for more information.
Either the server ID or its name can be used with the DEALLOCATE DATABASES command:
neo4j@system> DRYRUN DEALLOCATE DATABASES FROM SERVER '135ad202-5405-4d3c-9822-df39f59b823c';
When deallocating databases from servers, it is important to be mindful of the topology for each database to ensure that there are sufficient servers left in the cluster to satisfy the topologies of each database. Attempting to deallocate database(s) from a server that would result in less available servers than required fails with an error and no changes are made.
For example, if the cluster contains five servers and a database foo has a topology requiring three primary copies and two secondary copies, then it is not possible to deallocate any of the original five servers, without first adding and enabling new unconstrained servers, or altering the desired topology of foo to require fewer servers overall.
The command can be used with DRYRUN to get a view of how the databases would be moved from the deallocated server(s).
neo4j@system> DRYRUN DEALLOCATE DATABASES FROM SERVER '135ad202-5405-4d3c-9822-df39f59b823c';
+------------------------------------------------------------------------------------------------------------------------------------------+
| database | fromServerName | fromServerId | toServerName | toServerId | mode |
+------------------------------------------------------------------------------------------------------------------------------------------+
| "db1" | "server-3" | "135ad202-5405-4d3c-9822-df39f59b823c" | "server-5" | "00000003-b30a-434e-b9bf-1a5c8009773a" | "secondary" |
+------------------------------------------------------------------------------------------------------------------------------------------+
|
Deallocation is currently prevented in the following situations:
|
Once the command has been executed, the server changes state to Deallocating and it cannot readily be enabled again.
See dropped state for more information.
Dropping a server
Once DEALLOCATE DATABASES is executed against a server, its databases begin being moved.
It is important not to attempt the next step before SHOW SERVERS reports that the deallocating server is in the deallocated state.
For example, do not drop the server 135ad202-5405-4d3c-9822-df39f59b823c given the following output:
SHOW SERVERS;
+------------------------------------------------------------------------------------------------------------------+
| name | address | state | health | hosting |
+------------------------------------------------------------------------------------------------------------------+
| "135ad202-5405-4d3c-9822-df39f59b823c" | "localhost:7690" | "Deallocating" | "Available" | ["system", "foo"] |
+------------------------------------------------------------------------------------------------------------------+
The deallocation process may take some time, as foo must be successfully copied and started on a new server before it is stopped on 135ad202-5405-4d3c-9822-df39f59b823c in order to preserve the availability and fault tolerance of foo.
Once SHOW SERVERS reflects that the server is Deallocated and thus no longer hosts foo, the server may be dropped.
Either the server ID or its name can be used:
neo4j@system> DROP SERVER '135ad202-5405-4d3c-9822-df39f59b823c';
Once this command has been executed successfully, the Neo4j process on the server in question may be stopped.
Controlling a server’s metadata
Altering server options
A running server can have its options modified using the ALTER SERVER 'name' SET OPTIONS { option: value } command.
Either the ID or the name of the server can be used.
ALTER SERVER 'name' SET OPTIONS "{" option: value[,...] "}"
For example, to prevent a server from hosting databases in PRIMARY, execute the following:
neo4j@system> ALTER SERVER '25a7efc7-d063-44b8-bdee-f23357f89f01' SET OPTIONS {modeConstraint:'SECONDARY'};
Altering servers may cause databases to be moved, and should be performed with care.
For example, if the server 25a7efc7-d063-44b8-bdee-f23357f89f01 hosts database foo in primary mode when the above command is executed, then another server must begin hosting foo in primary mode.
Likewise, if ALTER SERVER '25a7efc7-d063-44b8-bdee-f23357f89f01' SET OPTIONS {allowedDatabases:['bar','baz']}; is executed, then foo is forced to move.
The possible options when altering a server are:
| Option | Allowed values | Description |
|---|---|---|
modeConstraint |
|
Databases may only be hosted on the server in the mode specified by the constraint.
|
allowedDatabases |
list of database names, e.g. |
Only databases matching the specified names may be hosted on the server.
This may not be specified in combination with |
deniedDatabases |
list of database names, e.g. |
Only databases not matching the specified names may be hosted on the server.
This may not be specified in combination with |
tags |
list of server tags, e.g. |
List of server tags used for load balancing and routing policies. |
|
Starting from 2025.12, database name patterns (wildcards) are supported, and the minimum length is reduced from |
As with the DEALLOCATE DATABASES FROM SERVER … command, if the alteration of a server’s options renders it impossible for the cluster to satisfy one or more of the databases' topologies, then the command fails and no changes are made.
|
Input provided to Any previously set values must be specified every time you run the For instance, you run two statements one after the other:
The execution of the second If you want to keep both values
Always check the current configuration with |
Renaming a server
RENAME SERVER 'name' TO 'newName'
When first discovered, a server’s name defaults to the value of its generated server ID. However, as long as the server is enabled, this can be changed later using the following command:
neo4j@system> RENAME SERVER '25a7efc7-d063-44b8-bdee-f23357f89f01' TO 'eu-server-4';
This only affects the name of the server; the ID of the server remains fixed as 25a7efc7-d063-44b8-bdee-f23357f89f01.
Keep in mind that the name of the server must be unique among existing servers.
Error handling
Occasionally, servers in a cluster may suffer issues such as network partitions or process crashes.
The easiest way to observe these server failures is by executing SHOW SERVERS and checking for Unavailable in the health column.
|
An For more in depth monitoring of cluster and server health, see Monitor servers. |
If the issue with the Unavailable server proves permanent, then the server should be removed.
However, if the issue is temporary then it likely is not desirable to remove these servers entirely as this causes all their hosted databases to be moved.
Instead it is preferable to prevent those servers from being allocated any new databases to host, either as a result of databases being created or moved.
This is known as cordoning the server in question, and can be achieved by executing the following procedure against the system database:
neo4j@system> CALL dbms.cluster.cordonServer('25a7efc7-d063-44b8-bdee-f23357f89f01');
SHOW SERVERS should then reflect that the server in question is now in cordoned state.
Once the issue with the server has been resolved, the server can be returned to its previous enabled state as follows:
neo4j@system> ENABLE SERVER '25a7efc7-d063-44b8-bdee-f23357f89f01';
|
An unavailable server which has not been cordoned may still be allocated to host new databases. When the server recovers it observes that it is due to host these databases and begin catching up from some other available servers (if one exists). However, in the meantime those databases have reduced fault tolerance or, worse, reduced availability. See Disaster Recovery for more details. |
Glossary
- allocator
-
A component in the cluster that allocates databases to servers according to the topology constraints specified and an allocation strategy.
- asynchronous replication
-
Asynchronous replication is used by secondary copies to poll for new transactions, which means they cannot be guaranteed to have received the most recent transactions. This enables efficient scale-out of read-performance.
- Aura instance
-
A fully-managed DBMS represented by a single instance ID, that is running in the Neo4j Aura cloud.
- auto-commit transaction
-
An automatically committed transaction that contains a single query.
- Bolt protocol
-
Bolt is a protocol used for interaction between Neo4j instances and drivers.
- bookmark
-
A marker the client can request from the cluster to ensure that it is able to read its own writes so that the application’s state is consistent and only databases that have a copy of the bookmark are permitted to respond.
- category (Bloom)
-
A category is based on a node label and is defined in a Perspective as a way of visually distinguishing nodes with the same label(s).
- causal consistency
-
All servers in a cluster agree on the order in which transactions take place. The position of a server on the causal chain can be guaranteed using a bookmark.
- cluster
-
A Neo4j DBMS that spans multiple servers working together to increase fault tolerance and/or read scalability. Databases on a cluster may be configured to replicate across servers in the cluster thus achieving read scalability or high availability.
- client application
-
Software that interacts with a Neo4j server.
- commit
-
A commit is the successful completion of a transaction, which ensures durability of any changes made. For more details, visit Operations Manual → Transaction management.
- composite database
-
Composite databases are the means to access partitioned graph data with a single Cypher query.
- constraint
-
Constraints are sets of data modeling rules that ensure the data is consistent and reliable.
- Cypher®
-
Neo4j’s graph query language.
- data model
-
A data model defines how information is organized in a database. A good data model will make querying and understanding your data easier. In Neo4j, the data models have a graph structure.
- database
-
A database is a container used by the DBMS to manage and store graph data. The physical structure of data is controlled by the database.
- database vs graph
-
Databases are the physical containers of graph data. Graphs are the logical structure of data in Neo4j.
- Database Management System
-
Database Management System, or DBMS, capable of managing multiple databases. A DBMS may run on a single server, or span several servers configured as a cluster.
- database schema
-
The prescribed property existence and datatypes for nodes and relationships.
- deallocate
-
An act of removing a database from a server or a server from a cluster without loss of data or reduced fault tolerance.
- degree (of a node)
-
The number of relationships of a specific node; loops are counted twice.
- disaster recovery
-
A manual intervention to restore availability of a cluster, or databases within a cluster.
- driver
-
A software library that provides access to Neo4j from a particular programming language.
- election
-
In the event that the Raft leader becomes unresponsive, followers automatically trigger an election and vote for a new leader.
- entity
-
A node or a relationship.
- expression (Cypher)
-
A component of a Cypher query which produces values. It may be used in projections, as a predicate, or when setting properties on graph elements.
- fabric
-
Fabric is the architectural design of a unified system that provides a single access point to local or distributed graph data.
- fault tolerance
-
A guarantee that a cluster can maintain a database’s persistence and availability in the event of one or more servers failing.
- follower
-
A primary copy of a database acting as a follower, receives and acknowledges synchronous writes from the leader.
- Generative AI (GenAI)
-
A type of artificial intelligence (AI) system that generates text, images, or other media in response to prompts.
- graph
-
A logical representation of a set of nodes where some pairs are connected by relationships.
- index
-
Data structure that improves read performance of a database.
- knowledge graph
-
A specific type of graph that has an organizing principle so that a user (or a computer system) can reason about the underlying data. The organizing principle provides an additional layer of structure that adds context to support knowledge discovery.
- label
-
Marks a node as a member of a named and indexed subset. A node may be assigned zero or more labels.
- leader
-
A single primary copy of a database is designated as the leader. It receives all write transactions from clients and replicates writes synchronously to followers and asynchronously to secondary copies of the database.
- main database
-
In terms of Neo4j Enterprise Studio, the database(s) containing the user’s data. Can exist in the same Neo4j deployment as the tool asset database.
- motif
-
A description of a specific pattern within a graph.
- node
-
A node represents an entity or discrete object in your graph data model. Nodes can be connected by relationships, hold data in properties, and are classified by labels.
- operator
-
A symbol representing a mathematical or logical operation.
- parameter
-
Named value provided when running a Cypher statement.
- path
-
A sequence of nodes and the relationships connecting them, that does not contain duplicate relationships. Several paths can match a pattern.
- pattern
-
A specific arrangement of nodes and relationships that can be matched in a graph. A pattern follows a motif.
- perspective (Bloom)
-
A Perspective defines a certain business view or domain that can be found in the target Neo4j graph. A single Neo4j graph can be viewed through different Perspectives, each tailored for a different business purpose.
- primary
-
A copy of the database that is able to process write transactions and is eligible to be elected as a leader. It participates in fault tolerant writes as it is part of the majority required to acknowledge and commit write transactions.
- primary vs secondary
-
In a cluster, databases can operate in either primary or secondary mode. Primary databases are able to process write and read transactions, ensuring fault tolerance. Secondary databases are replicated asynchronously from primaries, and their main purpose is to provide read scaling within the cluster.
- project (Aura)
-
An isolated environment in the unified Aura console that contains its own database instances, configurations, and resources. Preceded by tenant in the classic Aura console.
- property
-
Properties are key-value pairs that are used for storing data on nodes and relationships.
- query (Cypher)
-
A statement that retrieves or writes information to a database.
- Raft group
-
A group of servers that are participating in hosting a particular database in primary mode.
- Raft group member
-
A server that is participating in a Raft group. A server can be a member of one or more groups.
- Raft log
-
A shared log between all Raft group members that is guaranteed to be consistently updated and viewed by those members. The log contains both database data and operational state of the Raft group.
- Raft protocol
-
The networking mechanism that enables a database to replicate its data across multiple servers to give high availability for accessing the data and high durability to the data stored.
- read scaling
-
Distributing query load by creating additional database copies hosted in secondary mode (read-only).
- relationship
-
A relationship represents a connection between nodes in your graph data model. Relationships connect a source node to a target node, hold data in properties, and are classified by type.
- secondary
-
An asynchronously replicated copy of the database that provides read scaling within the cluster.
- seed
-
A seed is a database dump or a full backup used to create a database on a cluster. This is sometimes called seeding.
- server
-
A physical machine, a virtual machine, or a container running an instance of Neo4j. Servers can be standalone or part of a cluster.
- session
-
A causally linked sequence of transactions.
- session consistency
-
An alternative name for Neo4j’s causal consistency.
- standalone
-
A single server running Neo4j and not part of a cluster.
- synchronous replication
-
Synchronous replication requires the leader primary to replicate a transaction and block the commit until a quorum of the follower primaries acknowledges that the transaction is successfully replicated. Once the transaction is replicated, the commit is allowed to proceed. This ensures data durability and consistency within the cluster.
- system database
-
A database used by Neo4j to store system information.
- tenant (Aura)
-
An isolated environment in the classic Aura console that contains its own database instances, configurations, and resources. Replaced by project in the unified Aura console.
- tool asset database
-
In terms of Neo4j Enterprise Studio, the database where tools' assets are stored. This can be in the same Neo4j deployment as the main database(s) or in a separate deployment.
- topology
-
A configuration that describes how the copies of a database should be spread across the servers in a cluster, see primary mode and secondary mode.
- transaction
-
A transaction comprises a unit of work performed against a database. It is treated in a coherent and reliable way, independent of other transactions. Transactions comply with the ACID consistency model (atomic, consistent, isolated, and durable).