1. 15 Oct, 2015 1 commit
  2. 07 Aug, 2015 1 commit
  3. 06 Aug, 2015 1 commit
    • antirez's avatar
      Replication: add REPLCONF CAPA EOF support. · ba323760
      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).
      ba323760
  4. 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
  5. 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
  6. 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
  7. 09 Jan, 2015 1 commit
  8. 03 Dec, 2014 2 commits
  9. 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
  10. 29 Oct, 2014 8 commits
  11. 06 Oct, 2014 1 commit
  12. 19 Sep, 2014 1 commit
  13. 08 Sep, 2014 1 commit
  14. 26 Aug, 2014 5 commits
  15. 18 Jul, 2014 8 commits
  16. 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
  17. 26 Jun, 2014 1 commit
  18. 23 Jun, 2014 1 commit
  19. 21 Jun, 2014 1 commit