1. 20 May, 2014 2 commits
    • antirez's avatar
      Cluster: forced failover implemented. · e84dcabf
      antirez authored
      Using CLUSTER FAILOVER FORCE it is now possible to failover a master in
      a forced way, which means:
      
      1) No check to understand if the master is up is performed.
      2) No data age of the slave is checked. Evan a slave with very old data
         can manually failover a master in this way.
      3) No chat with the master is attempted to reach its replication offset:
         the master can just be down.
      e84dcabf
    • antirez's avatar
      Cluster: bypass data_age check for manual failovers. · b5cdd42b
      antirez authored
      Automatic failovers only happen in Redis Cluster if the slave trying to
      be elected was disconnected from its master for no more than 10 times
      the node-timeout value. However there should be no such a check for
      manual failovers, since these are initiated by the sysadmin that, in
      theory, knows what she is doing when a slave is selected to be promoted.
      b5cdd42b
  2. 19 May, 2014 1 commit
  3. 12 May, 2014 9 commits
  4. 09 May, 2014 3 commits
  5. 08 May, 2014 3 commits
    • antirez's avatar
      Sentinel: log when a failover will be attempted again. · 6eadeb72
      antirez authored
      When a Sentinel performs a failover (successful or not), or when a
      Sentinel votes for a different Sentinel trying to start a failover, it
      sets a min delay before it will try to get elected for a failover.
      
      While not strictly needed, because if multiple Sentinels will try
      to failover the same master at the same time, only one configuration
      will eventually win, this serialization is practically very useful.
      Normal failovers are cleaner: one Sentinel starts to failover, the
      others update their config when the Sentinel performing the failover
      is able to get the selected slave to move from the role of slave to the
      one of master.
      
      However currently this timeout was implicit, so users could see
      Sentinels not reacting, after a failed failover, for some time, without
      giving any feedback in the logs to the poor sysadmin waiting for clues.
      
      This commit makes Sentinels more verbose about the delay: when a master
      is down and a failover attempt is not performed because the delay has
      still not elaped, something like that will be logged:
      
          Next failover delay: I will not start a failover
          before Thu May  8 16:48:59 2014
      6eadeb72
    • antirez's avatar
      Sentinel: generate +config-update-from event when a new config is received. · c738f0f4
      antirez authored
      This event makes clear, before the switch-master event is generated,
      that a Sentinel received a configuration update from another Sentinel.
      c738f0f4
    • antirez's avatar
      REDIS_ENCODING_EMBSTR_SIZE_LIMIT set to 39. · d8ffd2b2
      antirez authored
      The new value is the limit for the robj + SDS header + string +
      null-term to stay inside the 64 bytes Jemalloc arena in 64 bits
      systems.
      d8ffd2b2
  6. 07 May, 2014 9 commits
  7. 05 May, 2014 2 commits
    • antirez's avatar
      Redis 2.9.52 (Redis 3.0.0 beta-3). · b7a6a6c4
      antirez authored
      b7a6a6c4
    • antirez's avatar
      CLUSTER SET-CONFIG-EPOCH implemented. · c4c7389f
      antirez authored
      Initially Redis Cluster accepted that after cluster creation all the
      nodes were at configEpoch 0, evolving from zero as failovers happen.
      
      However later the semantic was made more strict in order to make sure a
      cluster has always all the master nodes with a different configEpoch,
      which is more robust in some corner case (especially resulting from
      errors by the system administrator).
      
      To assign different configEpochs to different nodes at startup was a
      task performed naturally by the config conflicts resolution algorithm
      (see the Cluster specification). However this works well only for small
      clusters or when there are actually just a few collisions, since it is
      designed for exceptional cases.
      
      When a large cluster is created hundred of nodes can be at epoch 0, so
      the conflict resolution code is slow to provide an unique config to each
      node. For this reason this new command was introduced. It can be called
      only when a node is totally fresh: no other nodes known, and configEpoch
      set to zero, so it is safe even against misuses.
      
      redis-trib will use the new command in order to start the cluster
      already setting an incremental unique config to every node.
      c4c7389f
  8. 28 Apr, 2014 10 commits
    • antirez's avatar
      CLIENT LIST speedup via peerid caching + smart allocation. · a11ae385
      antirez authored
      This commit adds peer ID caching in the client structure plus an API
      change and the use of sdsMakeRoomFor() in order to improve the
      reallocation pattern to generate the CLIENT LIST output.
      
      Both the changes account for a very significant speedup.
      a11ae385
    • antirez's avatar
      bb00154f
    • antirez's avatar
      Added new sdscatfmt() %u and %U format specifiers. · e285a570
      antirez authored
      This commit also fixes a bug in the implementation of sdscatfmt()
      resulting from stale references to the SDS string header after
      sdsMakeRoomFor() calls.
      e285a570
    • antirez's avatar
      sdscatfmt() added to SDS library. · 0ab06bb5
      antirez authored
      sdscatprintf() relies on printf() family libc functions and is sometimes
      too slow in critical code paths. sdscatfmt() is an alternative which is:
      
      1) Far less capable.
      2) Format specifier uncompatible.
      3) Faster.
      
      It is suitable to be used in those speed critical code paths such as
      CLIENT LIST output generation.
      0ab06bb5
    • antirez's avatar
      Process events with processEventsWhileBlocked() when blocked. · cdd2bd56
      antirez authored
      When we are blocked and a few events a processed from time to time, it
      is smarter to call the event handler a few times in order to handle the
      accept, read, write, close cycle of a client in a single pass, otherwise
      there is too much latency added for clients to receive a reply while the
      server is busy in some way (for example during the DB loading).
      cdd2bd56
    • antirez's avatar
      Accept multiple clients per iteration. · 357b039f
      antirez authored
      When the listening sockets readable event is fired, we have the chance
      to accept multiple clients instead of accepting a single one. This makes
      Redis more responsive when there is a mass-connect event (for example
      after the server startup), and in workloads where a connect-disconnect
      pattern is used often, so that multiple clients are waiting to be
      accepted continuously.
      
      As a side effect, this commit makes the LOADING, BUSY, and similar
      errors much faster to deliver to the client, making Redis more
      responsive when there is to return errors to inform the clients that the
      server is blocked in an not interruptible operation.
      357b039f
    • antirez's avatar
      AE_ERR -> ANET_ERR in acceptUnixHandler(). · ba861194
      antirez authored
      No actual changes since the value is the same.
      ba861194
    • antirez's avatar
      3acae3de
    • antirez's avatar
      clusterLoadConfig() REDIS_ERR retval semantics refined. · b008863e
      antirez authored
      We should return REDIS_ERR to signal we can't read the configuration
      because there is no config file only after checking errno, othewise
      we risk to rewrite an existing file that was not accessible for some
      other reason.
      b008863e
    • antirez's avatar
      Lock nodes.conf to avoid multiple processes using the same file. · 71d71814
      antirez authored
      This was a common source of problems among users.
      The solution adopted is not bullet-proof as if the user deletes the
      nodes.conf file manually, and starts a new instance with the same
      nodes.conf file path, two instances will use the same file. However
      following this reasoning the user may drop a nuclear bomb into the
      datacenter as well.
      71d71814
  9. 23 Apr, 2014 1 commit