Hi Oleg, Your understanding of both topics, in the current version of Akka, are correct. More specifically:
Is it possible to configure Akka Cluster with auto-downing so that with > 100% probability at each moment at most one cluster node thinks that he is > the leader (or singleton) even in case of cluster partitions? Some > emails/blog posts imply that requiring cluster partition to be majority > quorum does the trick? The auto-downing strategy currently provided is a rather naive one - just timeout based. It does not guard against split brains, which is why I would rather not encourage using auto-downing if your cluster needs any kind of "single" entity. The timer based auto downing works well for clusters where you have "many workers, but no master" for example, since causing a split need not end in a wrong "leader" being elected (since there is no leader). Yes, quorum would help making downing more safe (avoid split brains), however we have not implemented it yet (we are aware of the need and possibility of course). How to do it with auto-scaling clusters? In general it boils down to disallowing situations where the cluster can get "two majorities" (one side knows only old nodes, new side has more nodes and didn't reach quorum yet). One of the methods I'm aware of is described in the raft paper - section 6: membership changes <https://ramcloud.stanford.edu/raft.pdf>, which describes how it guarantees that at no point in time there can be "two majorities". We have not looked into implementing a better downing strategy yet but it's "on the radar" - it's not a given it would be raft based, needs more thought put into it. Am I correct that if two actors with the same persistence id work > concurrently on different cluster partitions the sequence numbers of events > will get mixed up? Correct, currently these sequence numbers are "source of truth" and mixing them up causes problems during replay. > Does it imply that if Akka Persistence is used with Akka Cluster Sharding > then Akka Cluster must guarantee uniqueness of ShardCoordinator? In fact, the cluster sharding *uses* persistence in order to survive the leader going down - so we can restore the shard allocation information once the new coordinator boots up. Yes, currently there is a hard requirement for "only one writer" in akka-persistence. This can be facilitated by either cluster-sharding or cluster-singletons. Slightly related "future work": We do have some CRDT work by Patrik Nordwall stashed (it's public as akka-data-replication) and will want to move it into Akka main at some point, those of course do not require any kind leaders in the cluster. Hope this helps! -- Konrad On Mon, Jan 12, 2015 at 5:55 PM, Oleg Mürk <[email protected]> wrote: > Hello! > > I would like to better understand and confirm consistency guarantees of > Akka Cluster and Persistence (ideally in terms of CAP and CRDTs) and > apologise if these questions have been discussed before :) > > Akka Cluster: > Is it possible to configure Akka Cluster with auto-downing so that with > 100% probability at each moment at most one cluster node thinks that he is > the leader (or singleton) even in case of cluster partitions? Some > emails/blog posts imply that requiring cluster partition to be majority > quorum does the trick? How to do it with auto-scaling clusters? > > Akka Persistence: > Am I correct that if two actors with the same persistence id work > concurrently on different cluster partitions the sequence numbers of events > will get mixed up? Does it imply that if Akka Persistence is used with Akka > Cluster Sharding then Akka Cluster must guarantee uniqueness of > ShardCoordinator? > > Some relevant messages that I managed to find are: > * Quorum-based split brain resolution > https://groups.google.com/d/msg/akka-user/UBSF3QQnGaM/r8YUEzr2EtEJ > https://groups.google.com/d/msg/akka-user/UBSF3QQnGaM/Jsg30N9ORQQJ > * Exactly *one* persistence actor with the same persistenceId active ? > https://groups.google.com/d/msg/akka-user/9E65YaKI2BE/SA3px74h0ugJ > https://groups.google.com/d/msg/akka-user/9E65YaKI2BE/hZon4M_z0AgJ > > Thank You! > Oleg Mürk > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
