4

In the new docs of Neo4j (23.1. Architecture) it says that:

When running Neo4j in HA mode there is always a single master and zero or more slaves. Compared to other master-slave replication setups Neo4j HA can handle write requests on all machines so there is no need to redirect those to the master specifically.

And in wikipedia about Multi-master replication

Multi-master replication is a method of database replication which allows data to be stored by a group of computers, and updated by any member of the group. All members are responsive to client data queries. The multi-master replication system is responsible for propagating the data modifications made by each member to the rest of the group, and resolving any conflicts that might arise between concurrent changes made by different members. Multi-master replication can be contrasted with master-slave replication, in which a single member of the group is designated as the "master" for a given piece of data and is the only node allowed to modify that data item. Other members wishing to modify the data item must first contact the master node. Allowing only a single master makes it easier to achieve consistency among the members of the group, but is less flexible than multi-master replication.

Is that means that is a multi-master architecture? What is the difference if not. Thanks

2 Answers 2

3

Neo4j is a master-slave cluster.

While you can write to slaves for safety, it will take locks on the master and affect your whole cluster's performance.

1

DISCLAIMER : Not a Neo4j expert

IMHO I would yes because the architecture link you gave sounds a lot like Percona XtraDB Cluster. The underlying replication scheme is driven by Galera.

skxs

In essence, all nodes check with one another before doing transaction commits or rollbacks. This also means that you can run inserts, updates, and deletes on any node in the cluster and will propagate to the other nodes.

In your architecture link, it says

All updates will however propagate from the master to other slaves eventually so a write from one slave may not be immediately visible on all other slaves

This means that when an update happens on one node, it may not be instantly visible on the other nodes due to replication lag (due to time it takes to setup transaction on the other node) until the commit occurs on those other nodes. The update would likely be visible on the node you just ran the update on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.