Get it, thank you Justin.
On Saturday, 18 March 2017 21:09:14 UTC+8, Justin du coeur wrote:
>
> I think you're being misled by the word "cluster". Keep in mind, a single
> JVM is still a perfectly valid "cluster" if it allows itself to be one. So
> it's very easy to fall into the trap where
I think you're being misled by the word "cluster". Keep in mind, a single
JVM is still a perfectly valid "cluster" if it allows itself to be one. So
it's very easy to fall into the trap where node A winds up as its own
cluster, and the other nodes are another cluster -- that's exactly what
>
> @Patrik, I have read the akka document about split brain resolver, but
> could you please explain a little bit more to help me understand why does
> it happen?
>
If node A is experiencing long GC, and then node A is firstly marked as
unreachable and then marked as down and later removed
Right, but that's an intentionally duplicative environment. In most Akka
systems, you want to have at *most* one Actor for any given entity. In
particular, if you are using Cluster Sharding and Akka Persistence,
duplication is a recipe for database corruption.
One might well be able to build a
You could leave it running without downing, but you must still have a
strategy for downing/removing crashed or stopped nodes. Also note that a
crash, cpu overload or a long GC are indistinguishable from a network
partition.
/Patrik
fre 17 mars 2017 kl. 19:24 skrev kant kodali
Why does one needs to take an approach of Split brain resolver when there
is something better? The problem of network partitions is well understood
in most distributed nosql databases. For example Cassandra continues to
operate with the nodes that are available/reachable/up during
network
