ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: ATOMIC caches consistency - IEP-12
Date Wed, 27 Dec 2017 03:14:26 GMT

As one of the prevention mechanisms for the scenario you describe, would it
be possible to send the update message to backup nodes in the order in
which they would become primary nodes? For example, if backup1 node is the
next in chain to become the primary node, then the current primary node
should send the update message to backup1 before it sends it to backup2.

In this case, if the primary and client nodes fail, then backup1 node will
become primary and will have the latest version of the data, no? Will this
solve the situation you describe, at least partially?


On Mon, Dec 25, 2017 at 7:23 AM, Yakov Zhdanov <yzhdanov@apache.org> wrote:

> Hello!
> I tried to summarize some ideas on how to make ATOMIC caches stay
> consistent in case of topology changes.
> Imagine partitioned ATOMIC cache with 2 backups configured (primary + 2
> backup copies of the partition). One of possible scenarios to get to
> primary and backups divergence is the following - update initiating node
> sends update operation to primary node, primary node propagates update to 1
> of 2 backups and then dies. If initiating node crashes as well (and
> therefore cannot retry the operation) then in current implementation system
> comes to a situation when 2 copies of the partition present in cluster may
> be different. Note that both situations possible - new primary contains the
> latest update and backup does not and vice versa. New backup will be
> elected according to configured affinity and will rebalance the partition
> from random owner, but copies may not be consistent due to described above.
> This problem does not affect TRANSACTIONAL caches as 2PC protocol deals
> with scenarios of the kind very well.
> Here is the link to IEP -
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 12+Make+ATOMIC+Caches+Consistent+Again
> Sam, Alex G, Vladimir, please share your thoughts.
> --Yakov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message