I ran into the following on a CORE-only cluster: "No write operations are allowed directly on this database. Writes must pass through the leader. The role of this server is: FOLLOWER".
I access the node via HTTP, not Bolt (Because we started the project in PHP, when there was no Bolt connecort yet
The word FOLLOWER is self-explanatory, but in the cluster picture, it is also stated that CORE are meant for Read and Write
So, the question is: Why may not I write on that CORE which is meant for Read-Write?
Optionally: How can I make a multi-LEADER CORE cluster?
These terms are from the underlying raft consensus algorithm. A follower receives updates from the leader. A leader decides to commit a transaction based on the number of followers that confirmed that they have received an update.
A follower is also a candidate to become a leader when a leader election is triggered.
A read replica receives updates, but does not count towards consensus. It also will never become a leader. Read replicas are a bit like the database equivalent of a content-delivery network.
The reason you can't write to a follower is that there is no internal forwarding to the leader. The bolt drivers handle routing on the client-side by receiving routing information and relying on explicit read or write session types to decide where to send a given query.
Thank you @abk ,
If I understand correctly, despite I set a 100 nodes CORE cluster up , only one is LEADER, so that this only one can receive writes?
But if I set a 100 nodes CORE cluster up, it is to be able to share (round robin or random, whatever) things amoung all (or most) nodes!
I mean, it missis the "cluster" side of the definition.
A correction, it is possible to request server-side routing as explained in the Internals of clustering - Operations Manual .
Theoretically server-side routing would also forward http requests. I'm double checking on this as our documentation does not indicate whether or not it is possible. Will update this thread with whatever I learn.
Regarding clusters: the primary purpose of the cluster is resilience to failure. For reading, you can easily scale up read capacity by adding more members. However write operations are always serialized transactions. The data consistency guarantees would require multiple writers to coordinate their writes, returning to a serialized operation. Multiple writers are only possible with isolated data. A graph, by definition, is connected.
The way to crack that is to allow multiple graphs, which can then be independently updated. The problem is then what to do about querying across the independent graphs. That is the problem space of Neo4j Fabric.
Does that make sense?