1. 23 Apr, 2014 1 commit
  2. 16 Apr, 2014 9 commits
  3. 21 Mar, 2014 1 commit
  4. 11 Mar, 2014 17 commits
  5. 05 Mar, 2014 1 commit
    • 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
  6. 11 Feb, 2014 5 commits
  7. 10 Feb, 2014 6 commits
    • antirez's avatar
      Cluster: on resharding upgrade version of receiving node. · 2e3f6b0f
      antirez authored
      The node receiving the hash slot needs to have a version that wins over
      the other versions in order to force the ownership of the slot.
      
      However the current code is far from perfect since a failover can happen
      during the manual resharding. The fix is a work in progress but the
      bottom line is that the new version must either be voted as usually,
      set by redis-trib manually after it makes sure can't be used by other
      nodes, or reserved configEpochs could be used for manual operations (for
      example odd versions could be never used by slaves and are always used
      by CLUSTER SETSLOT NODE).
      2e3f6b0f
    • antirez's avatar
      Cluster: fsync at every SETSLOT command puts too pressure on disks. · a221ae5c
      antirez authored
      During slots migration redis-trib can send a number of SETSLOT commands.
      Fsyncing every time is a bit too much in production as verified
      empirically.
      
      To make sure configs are fsynced on all nodes after a resharding
      redis-trib may send something like CLUSTER CONFSYNC.
      
      In this case fsyncs were not providing too much value since anyway
      processes can crash in the middle of the resharding of an hash slot, and
      redis-trib should be able to recover from this condition anyway.
      a221ae5c
    • antirez's avatar
      Cluster: conditions to clear "migrating" on slot for SETSLOT ... NODE changed. · 77c6fa65
      antirez authored
      If the slot is manually assigned to another node, clear the migrating
      status regardless of the fact it was previously assigned to us or not,
      as long as we no longer have keys for this slot.
      
      This avoid a race during slots migration that may leave the slot in
      migrating status in the source node, since it received an update message
      from the destination node that is already claiming the slot.
      
      This way we are sure that redis-trib at the end of the slot migration is
      always able to close the slot correctly.
      77c6fa65
    • antirez's avatar
      Cluster: don't update slave's master if we don't know it. · cc97305e
      antirez authored
      There is no way we can update the slave's node->slaveof pointer if we
      don't know the master (no node with such an ID in our tables).
      cc97305e
    • antirez's avatar
      fa6f4f21
    • antirez's avatar
      30214fff