1. 07 Aug, 2015 1 commit
  2. 06 Aug, 2015 1 commit
    • antirez's avatar
      Replication: add REPLCONF CAPA EOF support. · 6974e69f
      antirez authored
      Add the concept of slaves capabilities to Redis, the slave now presents
      to the Redis master with a set of capabilities in the form:
      
          REPLCONF capa SOMECAPA capa OTHERCAPA ...
      
      This has the effect of setting slave->slave_capa with the corresponding
      SLAVE_CAPA macros that the master can test later to understand if it
      the slave will understand certain formats and protocols of the
      replication process. This makes it much simpler to introduce new
      replication capabilities in the future in a way that don't break old
      slaves or masters.
      
      This patch was designed and implemented together with Oran Agra
      (@oranagra).
      6974e69f
  3. 05 Aug, 2015 2 commits
    • antirez's avatar
      Make sure we re-emit SELECT after each new slave full sync setup. · 39994c24
      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.
      39994c24
    • antirez's avatar
      PSYNC initial offset fix. · 4b010572
      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.
      4b010572
  4. 09 Jan, 2015 1 commit
  5. 03 Dec, 2014 2 commits
  6. 11 Nov, 2014 1 commit
    • antirez's avatar
      Diskless SYNC: fix RDB EOF detection. · a5fcf44f
      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.
      a5fcf44f
  7. 29 Oct, 2014 9 commits
  8. 06 Oct, 2014 1 commit
  9. 08 Sep, 2014 1 commit
  10. 27 Aug, 2014 5 commits
  11. 18 Jul, 2014 1 commit
    • antirez's avatar
      PubSub clients refactoring and new PUBSUB flag. · 294bcfc4
      antirez authored
      The code tested many times if a client had active Pub/Sub subscriptions
      by checking the length of a list and dictionary where the patterns and
      channels are stored. This was substituted with a client flag called
      REDIS_PUBSUB that is simpler to test for. Moreover in order to manage
      this flag some code was refactored.
      
      This commit is believed to have no effects in the behavior of the
      server.
      294bcfc4
  12. 09 Jul, 2014 6 commits
  13. 27 Jun, 2014 2 commits
    • antirez's avatar
      COMMANDS command renamed COMMAND. · 53377f8c
      antirez authored
      53377f8c
    • Matt Stancliff's avatar
      Cluster: Add COMMANDS command · fdc5dbd5
      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.
      fdc5dbd5
  14. 26 Jun, 2014 1 commit
  15. 23 Jun, 2014 1 commit
  16. 21 Jun, 2014 5 commits
    • antirez's avatar
      New features for CLIENT KILL. · 09dc6dad
      antirez authored
      09dc6dad
    • antirez's avatar
      Assign an unique non-repeating ID to each new client. · cad13223
      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.
      cad13223
    • antirez's avatar
      Client types generalized. · b6a26b52
      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.
      b6a26b52
    • antirez's avatar
      ROLE command added. · 41a15205
      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.
      41a15205
    • antirez's avatar
      CLIENT LIST speedup via peerid caching + smart allocation. · d8d415e7
      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.
      d8d415e7