ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: How does it ensure that the primary partition has already synchronized to backup partition when during rebalance
Date Tue, 12 Jul 2016 23:09:54 GMT
Hi,

The answers are inline:

Hi, all
>       I am researching the cluster rebalance,  and the sync mode
> is CacheWriteSynchronizationMode.PRIMARY_SYNC, when rebalance completed,
> how does it ensure that the primary partition has already synchronized with
> backup partition because it possible have write request during rebalancing
> ?
>

If a write request comes in during the partition rebalancing, the write
request proceeds and updates the cache entry. If a rebalance request comes
in and sees that an entry is not in initial state, the rebalance request is
ignored. See GridCacheMapEntry#initialValue(CacheObject, GridCacheVersion,
long, long, boolean, AffinityTopologyVersion, ...) method. In other words,
write requests for a key always 'win' over rebalancing.


>      And I have find the method
> GridDhtPartitionsExchangeFuture.waitPartitionRelease() is using to wait the
> partition future to complete, however, this method does not ensure that all
> futures are really completed,  it only set timeout(total timeout is 20
> seconds) to the future, when timeout, it returned.
>

This is not true, note that this method actually loops. If a timeout
occurs, the IgniteInternalFuture#get(long) method will throw
IgniteFutureTimeoutException, which is caught in this method and pending
transactions are printed for debug/information purposes. This method will
never return unless partition release future is completed.


>      So,  how does it ensure that the primary partition has already
> synchronized with backup partition when rebalance completed ? In other
> words, how does it ensure that the data is consistency when rebalance
> completed?
>

Rebalancing is a pretty complex process, but in short, this is ensured by
three points:

   - Write requests are always sent to all partition holders.
   - Write requests always win over rebalance reqyests
   - Ignite waits for all 'old' transactions to complete before running
   rebalancing on a new version of topology.

Mime
View raw message