1. 05 Aug, 2015 2 commits
    • antirez's avatar
      Make sure we re-emit SELECT after each new slave full sync setup. · 27c0ab23
      antirez authored
      In previous commits we moved the FULLRESYNC to the moment we start the
      BGSAVE, so that the offset we provide is the right one. However this
      also means that we need to re-emit the SELECT statement every time a new
      slave starts to accumulate the changes.
      
      To obtian this effect in a more clean way, the function that sends the
      FULLRESYNC reply was overloaded with a more important role of also doing
      this and chanigng the slave state. So it was renamed to
      replicationSetupSlaveForFullResync() to better reflect what it does now.
      27c0ab23
    • antirez's avatar
      PSYNC initial offset fix. · 9d297218
      antirez authored
      This commit attempts to fix a bug involving PSYNC and diskless
      replication (currently experimental) found by Yuval Inbar from Redis Labs
      and that was later found to have even more far reaching effects (the bug also
      exists when diskstore is off).
      
      The gist of the bug is that, a Redis master replies with +FULLRESYNC to
      a PSYNC attempt that fails and requires a full resynchronization.
      However, the baseline offset sent along with FULLRESYNC was always the
      current master replication offset. This is not ok, because there are
      many reasosn that may delay the RDB file creation. And... guess what,
      the master offset we communicate must be the one of the time the RDB
      was created. So for example:
      
      1) When the BGSAVE for replication is delayed since there is one
         already but is not good for replication.
      2) When the BGSAVE is not needed as we attach one currently ongoing.
      3) When because of diskless replication the BGSAVE is delayed.
      
      In all the above cases the PSYNC reply is wrong and the slave may
      reconnect later claiming to need a wrong offset: this may cause
      data curruption later.
      9d297218
  2. 24 Mar, 2015 1 commit
    • antirez's avatar
      Replication: disconnect blocked clients when switching to slave role. · 7e78ab4b
      antirez authored
      Bug as old as Redis and blocking operations. It's hard to trigger since
      only happens on instance role switch, but the results are quite bad
      since an inconsistency between master and slave is created.
      
      How to trigger the bug is a good description of the bug itself.
      
      1. Client does "BLPOP mylist 0" in master.
      2. Master is turned into slave, that replicates from New-Master.
      3. Client does "LPUSH mylist foo" in New-Master.
      4. New-Master propagates write to slave.
      5. Slave receives the LPUSH, the blocked client get served.
      
      Now Master "mylist" key has "foo", Slave "mylist" key is empty.
      
      Highlights:
      
      * At step "2" above, the client remains attached, basically escaping any
        check performed during command dispatch: read only slave, in that case.
      * At step "5" the slave (that was the master), serves the blocked client
        consuming a list element, which is not consumed on the master side.
      
      This scenario is technically likely to happen during failovers, however
      since Redis Sentinel already disconnects clients using the CLIENT
      command when changing the role of the instance, the bug is avoided in
      Sentinel deployments.
      
      Closes #2473.
      7e78ab4b
  3. 13 Jan, 2015 1 commit
    • antirez's avatar
      Cluster: clusterMsgDataGossip structure, explict padding + minor stuff. · 45e2a26d
      antirez authored
      Also explicitly set version to 0, add a protocol version define, improve
      comments in the gossip structure.
      
      Note that the structure layout is the same after the change, we are just
      making the padding explicit with an additional not used 16 bits field.
      So this commit is still able to talk with the previous versions of
      cluster nodes.
      45e2a26d
  4. 09 Jan, 2015 1 commit
  5. 03 Dec, 2014 2 commits
  6. 12 Nov, 2014 1 commit
    • antirez's avatar
      Diskless SYNC: fix RDB EOF detection. · 90911905
      antirez authored
      RDB EOF detection was relying on the final part of the RDB transfer to
      be a magic 40 bytes EOF marker. However as the slave is put online
      immediately, and because of sockets timeouts, the replication stream is
      actually contiguous with the RDB file.
      
      This means that to detect the EOF correctly we should either:
      
      1) Scan all the stream searching for the mark. Sucks CPU-wise.
      2) Start to send the replication stream only after an acknowledge.
      3) Implement a proper chunked encoding.
      
      For now solution "2" was picked, so the master does not start to send
      ASAP the stream of commands in the case of diskless replication. We wait
      for the first REPLCONF ACK command from the slave, that certifies us
      that the slave correctly loaded the RDB file and is ready to get more
      data.
      90911905
  7. 29 Oct, 2014 8 commits
  8. 06 Oct, 2014 1 commit
  9. 19 Sep, 2014 1 commit
  10. 08 Sep, 2014 1 commit
  11. 26 Aug, 2014 5 commits
  12. 18 Jul, 2014 8 commits
  13. 27 Jun, 2014 2 commits
    • antirez's avatar
      COMMANDS command renamed COMMAND. · 3364b2d1
      antirez authored
      3364b2d1
    • Matt Stancliff's avatar
      Cluster: Add COMMANDS command · 60d62a99
      Matt Stancliff authored
      COMMANDS returns a nested multibulk reply for each
      command in the command table.  The reply for each
      command contains:
        - command name
        - arity
        - array of command flags
        - start key position
        - end key position
        - key offset step
        - optional: if the keys are not deterministic and
          Redis uses an internal key evaluation function,
          the 6th field appears and is defined as a status
          reply of: REQUIRES ARGUMENT PARSING
      
      Cluster clients need to know where the keys are in each
      command to implement proper routing to cluster nodes.
      
      Redis commands can have multiple keys, keys at offset steps, or other
      issues where you can't always assume the first element after
      the command name is the cluster routing key.
      
      Using the information exposed by COMMANDS, client implementations
      can have live, accurate key extraction details for all commands.
      
      Also implements COMMANDS INFO [commands...] to return only a
      specific set of commands instead of all 160+ commands live in Redis.
      60d62a99
  14. 26 Jun, 2014 1 commit
  15. 23 Jun, 2014 1 commit
  16. 21 Jun, 2014 4 commits
    • antirez's avatar
      New features for CLIENT KILL. · ca262a58
      antirez authored
      ca262a58
    • antirez's avatar
      Assign an unique non-repeating ID to each new client. · b7dd4518
      antirez authored
      This will be used by CLIENT KILL and is also a good way to ensure a
      given client is still the same across CLIENT LIST calls.
      
      The output of CLIENT LIST was modified to include the new ID, but this
      change is considered to be backward compatible as the API does not imply
      you can do positional parsing, since each filed as a different name.
      b7dd4518
    • antirez's avatar
      Client types generalized. · d97d1a64
      antirez authored
      Because of output buffer limits Redis internals had this idea of type of
      clients: normal, pubsub, slave. It is possible to set different output
      buffer limits for the three kinds of clients.
      
      However all the macros and API were named after output buffer limit
      classes, while the idea of a client type is a generic one that can be
      reused.
      
      This commit does two things:
      
      1) Rename the API and defines with more general names.
      2) Change the class of clients executing the MONITOR command from "slave"
         to "normal".
      
      "2" is a good idea because you want to have very special settings for
      slaves, that are not a good idea for MONITOR clients that are instead
      normal clients even if they are conceptually slave-alike (since it is a
      push protocol).
      
      The backward-compatibility breakage resulting from "2" is considered to
      be minimal to care, since MONITOR is a debugging command, and because
      anyway this change is not going to break the format or the behavior, but
      just when a connection is closed on big output buffer issues.
      d97d1a64
    • antirez's avatar
      ROLE command added. · 9b460e80
      antirez authored
      The new ROLE command is designed in order to provide a client with
      informations about the replication in a fast and easy to use way
      compared to the INFO command where the same information is also
      available.
      9b460e80