1. 20 Mar, 2013 3 commits
    • antirez's avatar
      Cluster: master node must clear its hash slots when turning into a slave. · e006407f
      antirez authored
      When a master turns into a slave after a failover event, make sure to
      clear the assigned slots before setting up the replication, as a slave
      should never claim slots in an explicit way, but just take over the
      master slots when replacing its master.
      e006407f
    • antirez's avatar
      Cluster: new flag PROMOTED introduced. · 506f9a42
      antirez authored
      A slave node set this flag for itself when, after receiving authorization
      from the majority of nodes, it turns itself into a master.
      
      At the same time now this flag is tested by nodes receiving a PING
      message before reconfiguring after a failover event. This makes the
      system more robust: even if currently there is no way to manually turn
      a slave into a master it is possible that we'll have such a feature in
      the future, or that simply because of misconfiguration a node joins the
      cluster as master while others believe it's a slave. This alone is now
      no longer enough to trigger reconfiguration as other nodes will check
      for the PROMOTED flag.
      
      The PROMOTED flag is cleared every time the node is turned back into a
      replica of some other node.
      506f9a42
    • antirez's avatar
      Cluster: add sender flags in cluster bus messages header. · 026b9483
      antirez authored
      Sender flags were not propagated for the sender, but only for nodes in
      the gossip section. This is odd and in the next commits we'll need to
      get updated flags for the sender node, so this commit adds a new field
      in the cluster messages header.
      
      The message header is the same size as we reused some free space that
      was marked as 'unused' because of alignment concerns.
      026b9483
  2. 19 Mar, 2013 4 commits
  3. 15 Mar, 2013 11 commits
  4. 14 Mar, 2013 5 commits
  5. 13 Mar, 2013 10 commits
  6. 12 Mar, 2013 6 commits
  7. 11 Mar, 2013 1 commit
    • antirez's avatar
      activeExpireCycle() smarter with many DBs and under expire pressure. · 2d851333
      antirez authored
      activeExpireCycle() tries to test just a few DBs per iteration so that
      it scales if there are many configured DBs in the Redis instance.
      However this commit makes it a bit smarter when one a few of those DBs
      are under expiration pressure and there are many many keys to expire.
      
      What we do is to remember if in the last iteration had to return because
      we ran out of time. In that case the next iteration we'll test all the
      configured DBs so that we are sure we'll test again the DB under
      pressure.
      
      Before of this commit after some mass-expire in a given DB the function
      tested just a few of the next DBs, possibly empty, a few per iteration,
      so it took a long time for the function to reach again the DB under
      pressure. This resulted in a lot of memory being used by already expired
      keys and never accessed by clients.
      2d851333