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.
