[infinispan-dev] ISPN-263 and handling partitions

Sanne Grinovero sanne at infinispan.org
Thu Apr 25 10:30:04 EDT 2013


Simple solution:
each node works on power-via-ethernet: when the cable is unplugged, it's down.

Then we think of a redundant design at the physical network level to
make it unlikely.

Sanne


On 24 April 2013 16:38, Manik Surtani <msurtani at redhat.com> wrote:
>
> On 24 Apr 2013, at 16:08, Mircea Markus <mmarkus at redhat.com> wrote:
>
>>
>> On 22 Apr 2013, at 17:43, Manik Surtani wrote:
>>
>>> On 22 Apr 2013, at 14:47, Bela Ban <bban at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 4/19/13 11:51 AM, Sanne Grinovero wrote:
>>>>> TBH I'm not understanding which problem this thread is about :)
>>>>>
>>>>> Surely network partitions are a problem, but there are many forms of
>>>>> "partition", and many different opinions of what an "acceptable"
>>>>> behaviour is that the grid should implement, which largely depend on
>>>>> assumptions the client application is making.
>>>>
>>>>
>>>> This thread is not about providing different application data merge
>>>> policies, which is also something that needs to be done, but more likely
>>>> in the context of eventual consistency in Infinispan. This thread is
>>>> about a *primary partition* approach which says that only members in a
>>>> primary partition are allowed to make progress, and others aren't.
>>>>
>>>> 'No progress' needs to be defined, but so far I think we've agreed on a
>>>> notion of read-only members, which do provide access to data, but don't
>>>> allow modifications. One could also think about not even allowing reads
>>>> as the data might be stale. Perhaps this is configurable.
>>>
>>> +1
>>>
>>>> The idea is that if only a primary partition can make progress, and only
>>>> *one* primary partitions exists in the system at any time, then we can
>>>> simply overwrite the data of minority partitions with data from the
>>>> primary partition on a merge.
>>>>
>>>> So a primary partition approach is not about how to merge (possibly
>>>> conflicting) data after a cluster split heals, but about how to
>>>> *prevent* conflicting data in the first place.
>>>>
>>>> If you think about this in CAP terminology, we sacrifice availability in
>>>> favor of consistency.
>>>
>>> Precisely.  This would still follow the strongly consistent model.
>> I don't think consistency is preserved in at least the following situations:
>> - the read-only partition has more than numOwner members. Reads in the active partition would miss data. Also the conditional operation, that rely on existing data, perform incorrectly.
>
> Good point.
>
>> - data is deleted in the active partition but copies are kept in the read-only partition.
>> The 2nd problem can be solved with tombstones. The first problem cannot be solved and we can only target an eventual consistent cluster. That should be made very clear to the users.
>>
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


More information about the infinispan-dev mailing list