1. 09 Nov, 2016 1 commit
    • antirez's avatar
      PSYNC2: different improvements to Redis replication. · 2669fb83
      antirez authored
      The gist of the changes is that now, partial resynchronizations between
      slaves and masters (without the need of a full resync with RDB transfer
      and so forth), work in a number of cases when it was impossible
      in the past. For instance:
      
      1. When a slave is promoted to mastrer, the slaves of the old master can
      partially resynchronize with the new master.
      
      2. Chained slalves (slaves of slaves) can be moved to replicate to other
      slaves or the master itsef, without requiring a full resync.
      
      3. The master itself, after being turned into a slave, is able to
      partially resynchronize with the new master, when it joins replication
      again.
      
      In order to obtain this, the following main changes were operated:
      
      * Slaves also take a replication backlog, not just masters.
      
      * Same stream replication for all the slaves and sub slaves. The
      replication stream is identical from the top level master to its slaves
      and is also the same from the slaves to their sub-slaves and so forth.
      This means that if a slave is later promoted to master, it has the
      same replication backlong, and can partially resynchronize with its
      slaves (that were previously slaves of the old master).
      
      * A given replication history is no longer identified by the `runid` of
      a Redis node. There is instead a `replication ID` which changes every
      time the instance has a new history no longer coherent with the past
      one. So, for example, slaves publish the same replication history of
      their master, however when they are turned into masters, they publish
      a new replication ID, but still remember the old ID, so that they are
      able to partially resynchronize with slaves of the old master (up to a
      given offset).
      
      * The replication protocol was slightly modified so that a new extended
      +CONTINUE reply from the master is able to inform the slave of a
      replication ID change.
      
      * REPLCONF CAPA is used in order to notify masters that a slave is able
      to understand the new +CONTINUE reply.
      
      * The RDB file was extended with an auxiliary field that is able to
      select a given DB after loading in the slave, so that the slave can
      continue receiving the replication stream from the point it was
      disconnected without requiring the master to insert "SELECT" statements.
      This is useful in order to guarantee the "same stream" property, because
      the slave must be able to accumulate an identical backlog.
      
      * Slave pings to sub-slaves are now sent in a special form, when the
      top-level master is disconnected, in order to don't interfer with the
      replication stream. We just use out of band "\n" bytes as in other parts
      of the Redis protocol.
      
      An old design document is available here:
      
      https://gist.github.com/antirez/ae068f95c0d084891305
      
      However the implementation is not identical to the description because
      during the work to implement it, different changes were needed in order
      to make things working well.
      2669fb83
  2. 24 Aug, 2016 1 commit
  3. 27 Jul, 2016 1 commit
    • antirez's avatar
      Ability of slave to announce arbitrary ip/port to master. · 55385f99
      antirez authored
      This feature is useful, especially in deployments using Sentinel in
      order to setup Redis HA, where the slave is executed with NAT or port
      forwarding, so that the auto-detected port/ip addresses, as listed in
      the "INFO replication" output of the master, or as provided by the
      "ROLE" command, don't match the real addresses at which the slave is
      reachable for connections.
      55385f99
  4. 20 Jul, 2016 1 commit
  5. 13 Jun, 2016 1 commit
  6. 10 May, 2016 1 commit
  7. 19 Apr, 2016 1 commit
  8. 01 Feb, 2016 1 commit
  9. 07 Jan, 2016 1 commit
    • antirez's avatar
      New security feature: Redis protected mode. · edd4d555
      antirez authored
      An exposed Redis instance on the internet can be cause of serious
      issues. Since Redis, by default, binds to all the interfaces, it is easy
      to forget an instance without any protection layer, for error.
      
      Protected mode try to address this feature in a soft way, providing a
      layer of protection, but giving clues to Redis users about why the
      server is not accepting connections.
      
      When protected mode is enabeld (the default), and if there are no
      minumum hints about the fact the server is properly configured (no
      "bind" directive is used in order to restrict the server to certain
      interfaces, nor a password is set), clients connecting from external
      intefaces are refused with an error explaining what to do in order to
      fix the issue.
      
      Clients connecting from the IPv4 and IPv6 lookback interfaces are still
      accepted normally, similarly Unix domain socket connections are not
      restricted in any way.
      edd4d555
  10. 03 Dec, 2015 1 commit
  11. 15 Oct, 2015 1 commit
  12. 05 Oct, 2015 1 commit
  13. 26 Apr, 2015 1 commit
  14. 23 Apr, 2015 1 commit
  15. 19 Feb, 2015 2 commits
    • antirez's avatar
      0aa5acc8
    • antirez's avatar
      Example redis.conf binds just to 127.0.0.1. · 10246642
      antirez authored
      It's hard to pick a good approach here. A few arguments:
      
      1) There are many exposed instances on the internet.
      2) Changing the default when "bind" is not given is very dangerous,
         after an upgrade the server changes a fundamental behavior.
      3) Usually Redis, when used in a proper way, will be protected *and*
         accessed often from other computers, so this new default is likely
         not what most people want.
      4) However if users end with this default, they are using the example
         redis.conf: likely they are reading what is inside, and they'll see
         the warning.
      10246642
  16. 12 Feb, 2015 1 commit
  17. 09 Jan, 2015 1 commit
    • Matt Stancliff's avatar
      Supervise redis processes only if configured · 36a3b753
      Matt Stancliff authored
      Adds configuration option 'supervised [no | upstart | systemd | auto]'
      
      Also removed 'bzero' from the previous implementation because it's 2015.
      (We could actually statically initialize those structs, but clang
      throws an invalid warning when we try, so it looks bad even though it
      isn't bad.)
      
      Fixes #2264
      36a3b753
  18. 08 Jan, 2015 1 commit
  19. 02 Jan, 2015 1 commit
    • Matt Stancliff's avatar
      Config: Add quicklist, remove old list options · 02bb515a
      Matt Stancliff authored
      This removes:
        - list-max-ziplist-entries
        - list-max-ziplist-value
      
      This adds:
        - list-max-ziplist-size
        - list-compress-depth
      
      Also updates config file with new sections and updates
      tests to use quicklist settings instead of old list settings.
      02bb515a
  20. 02 Dec, 2014 1 commit
  21. 31 Oct, 2014 1 commit
  22. 27 Oct, 2014 1 commit
  23. 24 Oct, 2014 1 commit
  24. 29 Sep, 2014 5 commits
  25. 17 Sep, 2014 1 commit
  26. 08 Sep, 2014 1 commit
  27. 07 Aug, 2014 1 commit
  28. 28 Jul, 2014 1 commit
  29. 25 Jul, 2014 1 commit
  30. 02 Jul, 2014 1 commit
  31. 16 Jun, 2014 1 commit
    • antirez's avatar
      Client types generalized. · 56d26c23
      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.
      56d26c23
  32. 22 May, 2014 1 commit
  33. 23 Apr, 2014 1 commit
  34. 15 Apr, 2014 1 commit
  35. 21 Mar, 2014 1 commit