> given enough time any cluster of size N with auto-down will eventually 
end up as N single-node clusters. It is thus not a sustainable strategy 
unless you invest the manpower to constantly manually rebuild the cluster.

Do you mean that after the netsplit heals, clusters won't merge on their 
own? 

Theoretically, they could: once a leader node sees another node that thinks 
that it is a leader, they elect a leader among themselves, and nodes from 
the loser cluster leave that cluster and join the winner cluster. It's then 
up to the individual features to be able to cope with that. For instance, 
I'd expect Distributed Data to able to cope with that, since the ability 
merge is the central idea of CRDT. On the other hand, Akka Persistence 
won't be able to cope with that.

So the way I would use Cluster in this scenario is by not using features 
that are not "AP" (Akka Persistence, probably Akka Singleton --- but see 
question 3 in the original post), and instead using those that are --- 
Distributed Data, cluster-aware routing. The idea is that netsplits do 
happen, but they are transient, so most of the time the cluster operates as 
a single whole; during netsplit, it can be broken into several clusters, 
each of which will operate as before, but will need to merge once they 
rejoin. 

Of course, if clusters do not "merge" automatically, then it's a no-go. So 
--- could you confirm that it is the case? 

Regards
Igor

On Wednesday, August 30, 2017 at 9:33:16 PM UTC+3, rkuhn wrote:
>
> Another way of putting this is that given enough time any cluster of size 
> N with auto-down will eventually end up as N single-node clusters. It is 
> thus not a sustainable strategy unless you invest the manpower to 
> constantly manually rebuild the cluster.
>
> Regards, Roland 
>
> Sent from my iPhone
>
> On 30. Aug 2017, at 18:25, Justin du coeur <[email protected] 
> <javascript:>> wrote:
>
> On Wed, Aug 30, 2017 at 11:24 AM, Igor Baltiyskiy <[email protected] 
> <javascript:>> wrote:
>
>> I'd like to clarify the warning given in the documentation:
>>
>> > We recommend against using the auto-down feature of Akka Cluster in 
>> production. This is crucial for correct behavior if you use Cluster 
>> Singleton <http://doc.akka.io/docs/akka/2.5/scala/cluster-singleton.html> 
>> or Cluster Sharding 
>> <http://doc.akka.io/docs/akka/2.5/scala/cluster-sharding.html>, 
>> especially together with Akka Persistence 
>> <http://doc.akka.io/docs/akka/2.5/scala/persistence.html>. For Akka 
>> Persistence with Cluster Sharding it can result in corrupt data in case of 
>> network partitions.
>> (
>> http://doc.akka.io/docs/akka/2.5/scala/cluster-usage.html#auto-downing-do-not-use-
>> )
>>
>> This passage raises several questions:
>>
>> 1. Does it mean that auto-downing is *always* a bad idea? Or is it only 
>> a bad idea when using Cluster Singleton and Cluster Sharding, so that if 
>> I'm not using them, using auto-downing in production is perfectly fine?
>>
>
> It's a more or less *guaranteed* disaster in the long run with Cluster 
> Sharding; it's only a *likely* disaster without, depending on what your app 
> is doing.  But personally, I think it should never, ever be used.
>
> Look at it this way: the problem with auto-down is that it is likely, in 
> the long run, that you will eventually wind up in a Split Brain situation, 
> with two or more disconnected clusters, each of which thinks that it is The 
> One True Cluster and Source of Truth.  This will usually happen in a 
> realistic network, due to the vagaries of network traffic and the 
> fundamental dumbness of the auto-down algorithm.
>
> Now, ask yourself: if this is acceptable -- if it is okay to sometimes 
> *not* be a Cluster -- why are you using Clustering at all?
>
> Basically, if your nodes need to be able to share information in a 
> consistent way, you need Clustering, which means that Split-Brain is 
> deadly, which means that you must not use auto-down.  If the nodes *don't* 
> need to be sharing information, you probably shouldn't be bothering with 
> Clustering at all, so auto-down is irrelevant.
>
> That's the heart of the argument, and why I personally think auto-down 
> should be simply excised from the library entirely: it is *never* safe to 
> use in anything more than a toy environment, and its existence just 
> confuses people...
>
> -- 
> >>>>>>>>>> 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] <javascript:>.
> To post to this group, send email to [email protected] 
> <javascript:>.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
>>>>>>>>>>      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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to