1. 12 2月, 2013 8 次提交
    • A
      PSYNC: don't use the client buffer to send +CONTINUE and +FULLRESYNC. · 0ed6daa4
      antirez 提交于
      When we are preparing an handshake with the slave we can't touch the
      connection buffer as it'll be used to accumulate differences between
      the sent RDB file and what arrives next from clients.
      
      So in short we can't use addReply() family functions.
      
      However we just use write(2) because we know that the socket buffer is
      empty, since a prerequisite for SYNC to work is that the static buffer
      and the output list are empty, and in general it is not expected that a
      client SYNCs after doing some heavy I/O with the master.
      
      However a short write connection is explicitly handled to avoid
      fragility (we simply close the connection and the slave will retry).
      0ed6daa4
    • A
      d2a0348a
    • A
      da315d33
    • A
      41d64a75
    • A
      PSYNC: work in progress, preview #2, rebased to unstable. · 07888202
      antirez 提交于
      07888202
    • A
      Use the new unified protocol to send SELECT to slaves. · e34a35a5
      antirez 提交于
      SELECT was still transmitted to slaves using the inline protocol, that
      is conceived mostly for humans to type into telnet sessions, and is
      notably not understood by redis-cli --slave.
      
      Now the new protocol is used instead.
      e34a35a5
    • A
      Use replicationFeedSlaves() to send PING to slaves. · 4b83ad4e
      antirez 提交于
      A Redis master sends PING commands to slaves from time to time: doing
      this ensures that even if absence of writes, the master->slave channel
      remains active and the slave can feel the master presence, instead of
      closing the connection for timeout.
      
      This commit changes the way PINGs are sent to slaves in order to use the
      standard interface used to replicate all the other commands, that is,
      the function replicationFeedSlaves().
      
      With this change the stream of commands sent to every slave is exactly
      the same regardless of their exact state (Transferring RDB for first
      synchronization or slave already online). With the previous
      implementation the PING was only sent to online slaves, with the result
      that the output stream from master to slaves was not identical for all
      the slaves: this is a problem if we want to implement partial resyncs in
      the future using a global replication stream offset.
      
      TL;DR: this commit should not change the behaviour in practical terms,
      but is just something in preparation for partial resynchronization
      support.
      4b83ad4e
    • A
      Emit SELECT to slaves in a centralized way. · 7465ac7a
      antirez 提交于
      Before this commit every Redis slave had its own selected database ID
      state. This was not actually useful as the emitted stream of commands
      is identical for all the slaves.
      
      Now the the currently selected database is a global state that is set to
      -1 when a new slave is attached, in order to force the SELECT command to
      be re-emitted for all the slaves.
      
      This change is useful in order to implement replication partial
      resynchronization in the future, as makes sure that the stream of
      commands received by slaves, including SELECT commands, are exactly the
      same for every slave connected, at any time.
      
      In this way we could have a global offset that can identify a specific
      piece of the master -> slaves stream of commands.
      7465ac7a
  2. 11 2月, 2013 1 次提交
  3. 09 2月, 2013 3 次提交
  4. 08 2月, 2013 4 次提交
  5. 05 2月, 2013 6 次提交
  6. 04 2月, 2013 4 次提交
  7. 01 2月, 2013 1 次提交
  8. 31 1月, 2013 1 次提交
  9. 29 1月, 2013 2 次提交
  10. 28 1月, 2013 10 次提交