1. 06 Aug, 2015 5 commits
    • antirez's avatar
      syncWithMaster(): non blocking state machine. · 88c716a0
      antirez authored
      88c716a0
    • antirez's avatar
      flushSlavesOutputBuffers(): details clarified via comments. · 55cb64bb
      antirez authored
      Talking with @oranagra we had to reason a little bit to understand if
      this function could ever flush the output buffers of the wrong slaves,
      having online state but actually not being ready to receive writes
      before the first ACK is received from them (this happens with diskless
      replication).
      
      Next time we'll just read this comment.
      55cb64bb
    • antirez's avatar
      ce5761e0
    • antirez's avatar
      Client structure comments improved. · fd08839a
      antirez authored
      fd08839a
    • antirez's avatar
      Replication: add REPLCONF CAPA EOF support. · 3e6d4d59
      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).
      3e6d4d59
  2. 05 Aug, 2015 6 commits
  3. 04 Aug, 2015 1 commit
    • antirez's avatar
      PSYNC initial offset fix. · 292fec05
      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.
      292fec05
  4. 29 Jul, 2015 2 commits
  5. 28 Jul, 2015 8 commits
  6. 27 Jul, 2015 3 commits
  7. 26 Jul, 2015 6 commits
  8. 25 Jul, 2015 4 commits
  9. 24 Jul, 2015 1 commit
  10. 23 Jul, 2015 1 commit
    • antirez's avatar
      SDS: use type 8 if we are likely to append to the string. · ea9bd243
      antirez authored
      When empty strings are created, or when sdsMakeRoomFor() is called, we
      are likely into an appending pattern. Use at least type 8 SDS strings
      since TYPE 5 does not remember the free allocation size and requires to
      call sdsMakeRoomFor() at every new piece appended.
      ea9bd243
  11. 20 Jul, 2015 1 commit
  12. 17 Jul, 2015 2 commits