1. 05 Aug, 2015 3 commits
    • antirez's avatar
      b2ff48ef
    • antirez's avatar
      syncCommand() comments improved. · e684e726
      antirez authored
      e684e726
    • 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
  2. 01 Apr, 2015 1 commit
    • Oran Agra's avatar
      fixes to diskless replication. · c72253ec
      Oran Agra authored
      master was closing the connection if the RDB transfer took long time.
      and also sent PINGs to the slave before it got the initial ACK, in which case the slave wouldn't be able to find the EOF marker.
      c72253ec
  3. 24 Mar, 2015 1 commit
    • antirez's avatar
      Replication: disconnect blocked clients when switching to slave role. · 96aa6106
      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.
      96aa6106
  4. 03 Dec, 2014 1 commit
    • antirez's avatar
      Network bandwidth tracking + refactoring. · d56ef629
      antirez authored
      Track bandwidth used by clients and replication (but diskless
      replication is not tracked since the actual transfer happens in the
      child process).
      
      This includes a refactoring that makes tracking new instantaneous
      metrics simpler.
      d56ef629
  5. 11 Nov, 2014 2 commits
    • 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
    • antirez's avatar
  6. 29 Oct, 2014 21 commits
  7. 06 Oct, 2014 2 commits
  8. 26 Jun, 2014 1 commit
  9. 21 Jun, 2014 4 commits
  10. 05 Feb, 2014 1 commit
    • antirez's avatar
      Check for EAGAIN in sendBulkToSlave(). · 301a0cfc
      antirez authored
      Sometime an osx master with a Linux server over a slow link caused
      a strange error where osx called the writable function for
      the socket but actually apparently there was no room in the socket
      buffer to accept the write: write(2) call returned an EAGAIN error,
      that was not checked, so we considered write(2) == 0 always as a connection
      reset, which was unfortunate since the bulk transfer has to start again.
      
      Also more errors are logged with the WARNING level in the same code path
      now.
      301a0cfc
  11. 08 Jan, 2014 2 commits
    • antirez's avatar
      Don't send REPLCONF ACK to old masters. · 2a1a31ca
      antirez authored
      Masters not understanding REPLCONF ACK will reply with errors to our
      requests causing a number of possible issues.
      
      This commit detects a global replication offest set to -1 at the end of
      the replication, and marks the client representing the master with the
      REDIS_PRE_PSYNC flag.
      
      Note that this flag was called REDIS_PRE_PSYNC_SLAVE but now it is just
      REDIS_PRE_PSYNC as it is used for both slaves and masters starting with
      this commit.
      
      This commit fixes issue #1488.
      2a1a31ca
    • antirez's avatar
      418d3d35
  12. 22 Dec, 2013 1 commit
    • antirez's avatar
      Make new masters inherit replication offsets. · 4456ee11
      antirez authored
      Currently replication offsets could be used into a limited way in order
      to understand, out of a set of slaves, what is the one with the most
      updated data. For example this comparison is possible of N slaves
      were replicating all with the same master.
      
      However the replication offset was not transferred from master to slaves
      (that are later promoted as masters) in any way, so for instance if
      there were three instances A, B, C, with A master and B and C
      replication from A, the following could happen:
      
      C disconnects from A.
      B is turned into master.
      A is switched to master of B.
      B receives some write.
      
      In this context there was no way to compare the offset of A and C,
      because B would use its own local master replication offset as
      replication offset to initialize the replication with A.
      
      With this commit what happens is that when B is turned into master it
      inherits the replication offset from A, making A and C comparable.
      In the above case assuming no inconsistencies are created during the
      disconnection and failover process, A will show to have a replication
      offset greater than C.
      
      Note that this does not mean offsets are always comparable to understand
      what is, in a set of instances, since in more complex examples the
      replica with the higher replication offset could be partitioned away
      when picking the instance to elect as new master. However this in
      general improves the ability of a system to try to pick a good replica
      to promote to master.
      4456ee11