• antirez's avatar
    Better read-only behavior for expired keys in slaves. · 06e76bc3
    antirez authored
    Slaves key expire is orchestrated by the master. Sometimes the master
    will send the synthesized DEL to expire keys on the slave with a non
    trivial delay (when the key is not accessed, only the incremental expiry
    algorithm will expire it in background).
    
    During that time, a key is logically expired, but slaves still return
    the key if you GET (or whatever) it. This is a bad behavior.
    
    However we can't simply trust the slave view of the key, since we need
    the master to be able to send write commands to update the slave data
    set, and DELs should only happen when the key is expired in the master
    in order to ensure consistency.
    
    However 99.99% of the issues with this behavior is when a client which
    is not a master sends a read only command. In this case we are safe and
    can consider the key as non existing.
    
    This commit does a few changes in order to make this sane:
    
    1. lookupKeyRead() is modified in order to return NULL if the above
    conditions are met.
    2. Calls to lookupKeyRead() in commands actually writing to the data set
    are repliaced with calls to lookupKeyWrite().
    
    There are redundand checks, so for example, if in "2" something was
    overlooked, we should be still safe, since anyway, when the master
    writes the behavior is to don't care about what expireIfneeded()
    returns.
    
    This commit is related to  #1768, #1770, #2131.
    06e76bc3
hyperloglog.c 56.4 KB