Skip to content
Commits on May 19, 2014
  1. @antirez
  2. @antirez

    Merge pull request #1762 from trink/unstable

    Correct the HyperLogLog stale cache flag to prevent unnecessary computat...
    antirez committed May 19, 2014
  3. @antirez
  4. @antirez
  5. @antirez
Commits on May 18, 2014
  1. @trink

    Correct the HyperLogLog stale cache flag to prevent unnecessary compu…

    …tations.
    
    Set the MSB as documented.
    trink committed May 18, 2014
Commits on May 15, 2014
  1. @antirez

    Cluster: use clusterSetNodeAsMaster() during slave failover.

    clusterHandleSlaveFailover() was reimplementing what
    clusterSetNodeAsMaster() without any good reason.
    antirez committed May 15, 2014
  2. @antirez

    Cluster: clear todo_before_sleep flags when executing actions.

    Thanks to this change, when there is some code like:
    
        clusterDoBeforeSleep(CLUSTER_TODO_UPDATE_STATE|...);
        ... and later before returning to the event loop ...
        clusterUpdateState();
    
    The clusterUpdateState() function will clar the flag and will not be
    repeated in the clusterBeforeSleep() function. This especially important
    for config save/fsync flags which are slow to execute and not a good
    idea to repeat without a good reason.
    
    This is implemented for all the CLUSTER_TODO flags.
    antirez committed May 15, 2014
  3. @antirez
  4. @antirez

    CLUSTER RESET implemented.

    The new command is able to reset a cluster node so that it starts again
    as a fresh node. By default the command performs a soft reset (the same
    as calling it as CLUSTER RESET SOFT), and the following steps are
    performed:
    
    1) All slots are set as unassigned.
    2) The list of known nodes is flushed.
    3) Node is set as master if it is a slave.
    
    When an hard reset is performed with CLUSTER RESET HARD the following
    additional operations are performed:
    
    4) A new Node ID is created at random.
    5) Epochs are set to 0.
    
    CLUSTER RESET is useful both when the sysadmin wants to reconfigure a
    node with a different role (for example turning a slave into a master)
    and for testing purposes.
    
    It also may play a role in automatically provisioned Redis Clusters,
    since it allows to reset a node back to the initial state in order to be
    reconfigured.
    antirez committed May 15, 2014
  5. @antirez
Commits on May 14, 2014
  1. @antirez
  2. @antirez
  3. @antirez

    Cluster: better handling of stolen slots.

    The previous code handling a lost slot (by another master with an higher
    configuration for the slot) was defensive, considering it an error and
    putting the cluster in an odd state requiring redis-cli fix.
    
    This was changed, because actually this only happens either in a
    legitimate way, with failovers, or when the admin messed with the config
    in order to reconfigure the cluster. So the new code instead will try to
    make sure that the keys stored match the new slots map, by removing all
    the keys in the slots we lost ownership from.
    
    The function that deletes the keys from the lost slots is called only
    if the node does not lose all its slots (resulting in a reconfiguration
    as a slave of the node that got ownership). This is an optimization
    since the replication code will anyway flush all the instance data in
    a faster way.
    antirez committed May 14, 2014
  4. @antirez
Commits on May 13, 2014
  1. @antirez

    cluster.tcl: saner error handling.

    Better handling of connection errors in order to update the table and
    recovery, populate the startup nodes table after fetching the list of
    nodes.
    
    More work to do about it, it is still not as reliable as
    redis-rb-cluster implementation which is the minimal reference
    implementation for Redis Cluster clients.
    antirez committed May 14, 2014
  2. @antirez
Commits on May 12, 2014
  1. @antirez
  2. @antirez

    Cluster: forced failover implemented.

    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.
    antirez committed May 12, 2014
  3. @antirez

    Cluster: bypass data_age check for manual failovers.

    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.
    antirez committed May 12, 2014
  4. @theif @antirez

    Fixed possible buffer overflow bug if RDB file is corrupted.

    (Note: commit message modified by @antirez for clarity).
    theif committed with antirez May 12, 2014
  5. @theif @antirez

    fixed possible buffer overflow error

    theif committed with antirez May 12, 2014
  6. @antirez

    redis-trib create: use CONFIG SET-CONFIG-EPOCH before joining the clu…

    …ster.
    
    This way there is no need for the conflict resolution algo to be used in
    order to start with a cluster where each node has a different
    configEpoch.
    antirez committed May 12, 2014
  7. @antirez
  8. @antirez
  9. @antirez

    redis-trib.rb: MIGRATE hardcoded timeout set to 15 sec.

    Will be configurable / adaptive at some point but let's start with a
    saner value compared to 1 sec which is not a good idea for big data
    structures stored into a single key.
    antirez committed May 12, 2014
  10. @antirez

    RESTORE: reply with -BUSYKEY special error code.

    The error when the target key is busy was a generic one, while it makes
    sense to be able to distinguish between the target key busy error and
    the others easily.
    antirez committed May 12, 2014
Commits on May 10, 2014
  1. @antirez
Commits on May 9, 2014
  1. @antirez
  2. @antirez
  3. @antirez
  4. @antirez

    Cluster: bulk-accept new nodes connections.

    The same change was operated for normal client connections. This is
    important for Cluster as well, since when a node rejoins the cluster,
    when a partition heals or after a restart, it gets flooded with new
    connection attempts by all the other nodes trying to form a full
    mesh again.
    antirez committed May 9, 2014
  5. @antirez
Commits on May 8, 2014
  1. @antirez

    Sentinel: log when a failover will be attempted again.

    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
    antirez committed May 8, 2014
  2. @antirez

    Sentinel: generate +config-update-from event when a new config is rec…

    …eived.
    
    This event makes clear, before the switch-master event is generated,
    that a Sentinel received a configuration update from another Sentinel.
    antirez committed May 8, 2014
Something went wrong with that request. Please try again.