Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.
08-13-2020 10:51 PM
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...
Solved! Go to Solution.
08-15-2020 03:03 AM
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.
08-15-2020 03:03 AM
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.
All the sessions of the conference are now available online