1. 11 Mar, 2014 34 commits
  2. 05 Mar, 2014 6 commits
    • antirez's avatar
      4d5ba596
    • antirez's avatar
      Sentinel: more aggressive failover start desynchronization. · 313f8831
      antirez authored
      Sentinel needs to avoid split brain conditions due to multiple sentinels
      trying to get voted at the exact same time.
      
      So far some desynchronization was provided by fluctuating server.hz,
      that is the frequency of the timer function call. However the
      desynchonization provided in this way was not enough when using many
      Sentinel instances, especially when a large quorum value is used in
      order to force a greater degree of agreement (more than N/2+1).
      
      It was verified that it was likely to trigger a split brain
      condition, forcing the system to try again after a timeout.
      Usually the system will succeed after a few retries, but this is not
      optimal.
      
      This commit desynchronizes instances in a more effective way to make it
      likely that the first attempt will be successful.
      313f8831
    • antirez's avatar
      5ee23944
    • antirez's avatar
      d2e16801
    • antirez's avatar
      Document why we update peak memory in INFO. · 1d9eb47f
      antirez authored
      1d9eb47f
    • antirez's avatar
      Fix configEpoch assignment when a cluster slot gets "closed". · e4833ed8
      antirez authored
      This is still code to rework in order to use agreement to obtain a new
      configEpoch when a slot is migrated, however this commit handles the
      special case that happens when the nodes are just started and everybody
      has a configEpoch of 0. In this special condition to have the maximum
      configEpoch is not enough as the special epoch 0 is not unique (all the
      others are).
      
      This does not fixes the intrinsic race condition of a failover happening
      while we are resharding, that will be addressed later.
      e4833ed8