Permalink
Switch branches/tags
Nothing to show
Commits on Apr 30, 2018
Commits on Apr 26, 2018
  1. This adds SSL to hiredis via libressl

    josiahcarlson committed Apr 3, 2018
    * First test use-case is redis-benchmark
    * Switched to openssl
    * Added buffer clearing
    * Makefile support
    * More docs
Commits on Mar 26, 2018
  1. Redis 4.0.9

    antirez committed Mar 26, 2018
  2. fix missed call on freeaddrinfo

    soloestoy authored and antirez committed Mar 21, 2018
  3. anet: avoid double close

    soloestoy authored and antirez committed Mar 21, 2018
Commits on Mar 14, 2018
  1. Cluster: ability to prevent slaves from failing over their masters.

    antirez committed Mar 14, 2018
    This commit, in some parts derived from PR #3041 which is no longer
    possible to merge (because the user deleted the original branch),
    implements the ability of slaves to have a special configuration
    preventing that they try to start a failover when the master is failing.
    
    There are multiple reasons for wanting this, and the feautre was
    requested in issue #3021 time ago.
    
    The differences between this patch and the original PR are the
    following:
    
    1. The flag is saved/loaded on the nodes configuration.
    2. The 'myself' node is now flag-aware, the flag is updated as needed
       when the configuration is changed via CONFIG SET.
    3. The flag name uses NOFAILOVER instead of NO_FAILOVER to be consistent
       with existing NOADDR.
    4. The redis.conf documentation was rewritten.
    
    Thanks to @deep011 for the original patch.
Commits on Mar 2, 2018
Commits on Feb 28, 2018
  1. Actually use ae_flags to add AE_BARRIER if needed.

    antirez committed Feb 28, 2018
    Many thanks to @Plasma that spotted this problem reviewing the code.
Commits on Feb 27, 2018
  1. refactoring-make-condition-clear-for-rdb

    charsyam authored and antirez committed Feb 27, 2018
  2. ae.c: insetad of not firing, on AE_BARRIER invert the sequence.

    antirez committed Feb 27, 2018
    AE_BARRIER was implemented like:
    
        - Fire the readable event.
        - Do not fire the writabel event if the readable fired.
    
    However this may lead to the writable event to never be called if the
    readable event is always fired. There is an alterantive, we can just
    invert the sequence of the calls in case AE_BARRIER is set. This commit
    does that.
  3. AOF: fix a bug that may prevent proper fsyncing when fsync=always.

    antirez committed Feb 27, 2018
    In case the write handler is already installed, it could happen that we
    serve the reply of a query in the same event loop cycle we received it,
    preventing beforeSleep() from guaranteeing that we do the AOF fsync
    before sending the reply to the client.
    
    The AE_BARRIER mechanism, introduced in a previous commit, prevents this
    problem. This commit makes actual use of this new feature to fix the
    bug.
  4. Cluster: improve crash-recovery safety after failover auth vote.

    antirez committed Feb 27, 2018
    Add AE_BARRIER to the writable event loop so that slaves requesting
    votes can't be served before we re-enter the event loop in the next
    iteration, so clusterBeforeSleep() will fsync to disk in time.
    Also add the call to explicitly fsync, given that we modified the last
    vote epoch variable.
  5. ae.c: introduce the concept of read->write barrier.

    antirez committed Feb 23, 2018
    AOF fsync=always, and certain Redis Cluster bus operations, require to
    fsync data on disk before replying with an acknowledge.
    In such case, in order to implement Group Commits, we want to be sure
    that queries that are read in a given cycle of the event loop, are never
    served to clients in the same event loop iteration. This way, by using
    the event loop "before sleep" callback, we can fsync the information
    just one time before returning into the event loop for the next cycle.
    This is much more efficient compared to calling fsync() multiple times.
    
    Unfortunately because of a bug, this was not always guaranteed: the
    actual way the events are installed was the sole thing that could
    control. Normally this problem is hard to trigger when AOF is enabled
    with fsync=always, because we try to flush the output buffers to the
    socekt directly in the beforeSleep() function of Redis. However if the
    output buffers are full, we actually install a write event, and in such
    a case, this bug could happen.
    
    This change to ae.c modifies the event loop implementation to make this
    concept explicit. Write events that are registered with:
    
        AE_WRITABLE|AE_BARRIER
    
    Are guaranteed to never fire after the readable event was fired for the
    same file descriptor. In this way we are sure that data is persisted to
    disk before the client performing the operation receives an
    acknowledged.
    
    However note that this semantics does not provide all the guarantees
    that one may believe are automatically provided. Take the example of the
    blocking list operations in Redis.
    
    With AOF and fsync=always we could have:
    
        Client A doing: BLPOP myqueue 0
        Client B doing: RPUSH myqueue a b c
    
    In this scenario, Client A will get the "a" elements immediately after
    the Client B RPUSH will be executed, even before the operation is persisted.
    However when Client B will get the acknowledge, it can be sure that
    "b,c" are already safe on disk inside the list.
    
    What to note here is that it cannot be assumed that Client A receiving
    the element is a guaranteed that the operation succeeded from the point
    of view of Client B.
    
    This is due to the fact that the barrier exists within the same socket,
    and not between different sockets. However in the case above, the
    element "a" was not going to be persisted regardless, so it is a pretty
    synthetic argument.
Commits on Feb 19, 2018
  1. Track number of logically expired keys still in memory.

    antirez committed Feb 19, 2018
    This commit adds two new fields in the INFO output, stats section:
    
    expired_stale_perc:0.34
    expired_time_cap_reached_count:58
    
    The first field is an estimate of the number of keys that are yet in
    memory but are already logically expired. They reason why those keys are
    yet not reclaimed is because the active expire cycle can't spend more
    time on the process of reclaiming the keys, and at the same time nobody
    is accessing such keys. However as the active expire cycle runs, while
    it will eventually have to return to the caller, because of time limit
    or because there are less than 25% of keys logically expired in each
    given database, it collects the stats in order to populate this INFO
    field.
    
    Note that expired_stale_perc is a running average, where the current
    sample accounts for 5% and the history for 95%, so you'll see it
    changing smoothly over time.
    
    The other field, expired_time_cap_reached_count, counts the number
    of times the expire cycle had to stop, even if still it was finding a
    sizeable number of keys yet to expire, because of the time limit.
    This allows people handling operations to understand if the Redis
    server, during mass-expiration events, is able to collect keys fast
    enough usually. It is normal for this field to increment during mass
    expires, but normally it should very rarely increment. When instead it
    constantly increments, it means that the current workloads is using
    a very important percentage of CPU time to expire keys.
    
    This feature was created thanks to the hints of Rashmi Ramesh and
    Bart Robinson from Twitter. In private email exchanges, they noted how
    it was important to improve the observability of this parameter in the
    Redis server. Actually in big deployments, the amount of keys that are
    yet to expire in each server, even if they are logically expired, may
    account for a very big amount of wasted memory.
Commits on Feb 15, 2018
  1. Add doc comment about notification flags

    dvirsky authored and antirez committed Feb 14, 2018
  2. Remove the NOTIFY_MODULE flag and simplify the module notification fl…

    dvirsky authored and antirez committed Dec 7, 2017
    …ow if there aren't subscribers
  3. Document flags for notifications

    dvirsky authored and antirez committed Nov 27, 2017
  4. removed some trailing whitespaces

    dvirsky authored and antirez committed Nov 27, 2017
  5. removed hellonotify.c

    dvirsky authored and antirez committed Nov 27, 2017
  6. fixed test

    dvirsky authored and antirez committed Nov 27, 2017
  7. when a slave experiances an error on commands that come from master, …

    oranagra authored and antirez committed Feb 23, 2017
    …print to the log
    
    since slave isn't replying to it's master, these errors go unnoticed.
    since we don't expect the master to send garbadge to the slave, this should be safe.
    (as long as we don't log OOM errors there)
Commits on Feb 13, 2018
  1. getting rid of duplicated code

    charsyam authored and antirez committed Feb 13, 2018
  2. enlarged buffer given to ld2string

    guybe7 authored and antirez committed Jan 11, 2017