cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Cross Geo Multi Master support

Team,

Sorry if this is being answered before, I'm pretty new to Neo4j and I did a bit of research and couldn't find a proper response hence posting it here.

We are in the process of choosing a graph database for one of our big projects which has got user base across geographies (Asia, Europe, and US).We would like to know whether Neo4j supports multi-master (like Azure CosmosDb) where all nodes across Geo take both read and write and syncs between them without much delay. Reading through the docs, I could see that even the slave node can take write in the casual clustering, but I'm not sure whether my understanding is correct or whether that feature will suffice our cross geo multi-master requirement.

Is it possible to have DC's across geos in the approach mentioned here - https://neo4j.com/docs/operations-manual/current/clustering-advanced/multi-data-center/design/#multi...

1 ACCEPTED SOLUTION

At any given point of time one of the core instances is elected as leader the others are followers. Any write needs to be sent to the leader and if persistent as a consensus commit on the majority of cores. The other followers update themselves by pulls.

Your clients don't have to care about cluster specifics since the bolt protocol has a built-in routing table. On client side you only care about read transaction vs write transaction. The latter will always be routed to the leader.

You can assign your cluster members (both core and RR) into a server group and assign a routing policy, see https://neo4j.com/docs/operations-manual/current/clustering-advanced/multi-data-center/configuration.... With that you can define a setup where your reads happen in a local DC.

In a future version of Neo4j we might have support for multiple leaders - but there's not yet an ETA.

View solution in original post

1 REPLY 1

At any given point of time one of the core instances is elected as leader the others are followers. Any write needs to be sent to the leader and if persistent as a consensus commit on the majority of cores. The other followers update themselves by pulls.

Your clients don't have to care about cluster specifics since the bolt protocol has a built-in routing table. On client side you only care about read transaction vs write transaction. The latter will always be routed to the leader.

You can assign your cluster members (both core and RR) into a server group and assign a routing policy, see https://neo4j.com/docs/operations-manual/current/clustering-advanced/multi-data-center/configuration.... With that you can define a setup where your reads happen in a local DC.

In a future version of Neo4j we might have support for multiple leaders - but there's not yet an ETA.