1. 14 Oct, 2016 1 commit
    • antirez's avatar
      SWAPDB command. · c7a4e694
      antirez authored
      This new command swaps two Redis databases, so that immediately all the
      clients connected to a given DB will see the data of the other DB, and
      the other way around. Example:
      
          SWAPDB 0 1
      
      This will swap DB 0 with DB 1. All the clients connected with DB 0 will
      immediately see the new data, exactly like all the clients connected
      with DB 1 will see the data that was formerly of DB 0.
      
      MOTIVATION AND HISTORY
      ---
      
      The command was recently demanded by Pedro Melo, but was suggested in
      the past multiple times, and always refused by me.
      
      The reason why it was asked: Imagine you have clients operating in DB 0.
      At the same time, you create a new version of the dataset in DB 1.
      When the new version of the dataset is available, you immediately want
      to swap the two views, so that the clients will transparently use the
      new version of the data. At the same time you'll likely destroy the
      DB 1 dataset (that contains the old data) and start to build a new
      version, to repeat the process.
      
      This is an interesting pattern, but the reason why I always opposed to
      implement this, was that FLUSHDB was a blocking command in Redis before
      Redis 4.0 improvements. Now we have FLUSHDB ASYNC that releases the
      old data in O(1) from the point of view of the client, to reclaim memory
      incrementally in a different thread.
      
      At this point, the pattern can really be supported without latency
      spikes, so I'm providing this implementation for the users to comment.
      In case a very compelling argument will be made against this new command
      it may be removed.
      
      BEHAVIOR WITH BLOCKING OPERATIONS
      ---
      
      If a client is blocking for a list in a given DB, after the swap it will
      still be blocked in the same DB ID, since this is the most logical thing
      to do: if I was blocked for a list push to list "foo", even after the
      swap I want still a LPUSH to reach the key "foo" in the same DB in order
      to unblock.
      
      However an interesting thing happens when a client is, for instance,
      blocked waiting for new elements in list "foo" of DB 0. Then the DB
      0 and 1 are swapped with SWAPDB. However the DB 1 happened to have
      a list called "foo" containing elements. When this happens, this
      implementation can correctly unblock the client.
      
      It is possible that there are subtle corner cases that are not covered
      in the implementation, but since the command is self-contained from the
      POV of the implementation and the Redis core, it cannot cause anything
      bad if not used.
      
      Tests and documentation are yet to be provided.
      c7a4e694
  2. 07 Oct, 2016 1 commit
  3. 06 Oct, 2016 1 commit
  4. 19 Sep, 2016 1 commit
  5. 16 Sep, 2016 2 commits
  6. 15 Sep, 2016 2 commits
  7. 13 Sep, 2016 2 commits
    • antirez's avatar
      MEMORY OVERHEAD implemented (using Oran Agra initial implementation). · 8c84c962
      antirez authored
      This code was extracted from @oranagra PR #3223 and modified in order
      to provide only certain amounts of information compared to the original
      code. It was also moved from DEBUG to the newly introduced MEMORY
      command. Thanks to Oran for the implementation and the PR.
      
      It implements detailed memory usage stats that can be useful in both
      provisioning and troubleshooting memory usage in Redis.
      8c84c962
    • antirez's avatar
      objectComputeSize(): estimate collections sampling N elements. · 89dec692
      antirez authored
      For most tasks, we need the memory estimation to be O(1) by default.
      This commit also implements an initial MEMORY command.
      Note that objectComputeSize() takes the number of samples to check as
      argument, so MEMORY should be able to get the sample size as option
      to make precision VS CPU tradeoff tunable.
      
      Related to: PR #3223.
      89dec692
  8. 09 Sep, 2016 2 commits
  9. 09 Aug, 2016 1 commit
  10. 03 Aug, 2016 2 commits
    • antirez's avatar
      Security: Cross Protocol Scripting protection. · a81a92ca
      antirez authored
      This is an attempt at mitigating problems due to cross protocol
      scripting, an attack targeting services using line oriented protocols
      like Redis that can accept HTTP requests as valid protocol, by
      discarding the invalid parts and accepting the payloads sent, for
      example, via a POST request.
      
      For this to be effective, when we detect POST and Host: and terminate
      the connection asynchronously, the networking code was modified in order
      to never process further input. It was later verified that in a
      pipelined request containing a POST command, the successive commands are
      not executed.
      a81a92ca
    • antirez's avatar
      Fix comment over 80 cols. · ede6e22c
      antirez authored
      ede6e22c
  11. 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
  12. 21 Jul, 2016 1 commit
    • antirez's avatar
      Avoid simultaneous RDB and AOF child process. · 0a628e51
      antirez authored
      This patch, written in collaboration with Oran Agra (@oranagra) is a companion
      to 780a8b1d. Together the two patches should avoid that the AOF and RDB saving
      processes can be spawned at the same time. Previously conditions that
      could lead to two saving processes at the same time were:
      
      1. When AOF is enabled via CONFIG SET and an RDB saving process is
         already active.
      
      2. When the SYNC command decides to start an RDB saving process ASAP in
         order to serve a new slave that cannot partially resynchronize (but
         only if we have a disk target for replication, for diskless
         replication there is not such a problem).
      
      Condition "1" is not very severe but "2" can happen often and is
      definitely good at degrading Redis performances in an unexpected way.
      
      The two commits have the effect of always spawning RDB savings for
      replication in replicationCron() instead of attempting to start an RDB
      save synchronously. Moreover when a BGSAVE or AOF rewrite must be
      performed, they are instead just postponed using flags that will try to
      perform such operations ASAP.
      
      Finally the BGSAVE command was modified in order to accept a SCHEDULE
      option so that if an AOF rewrite is in progress, when this option is
      given, the command no longer returns an error, but instead schedules an
      RDB rewrite operation for when it will be possible to start it.
      0a628e51
  13. 20 Jul, 2016 1 commit
  14. 13 Jul, 2016 1 commit
    • antirez's avatar
      LRU: Make cross-database choices for eviction. · e423f76e
      antirez authored
      The LRU eviction code used to make local choices: for each DB visited it
      selected the best key to evict. This was repeated for each DB. However
      this means that there could be DBs with very frequently accessed keys
      that are targeted by the LRU algorithm while there were other DBs with
      many better candidates to expire.
      
      This commit attempts to fix this problem for the LRU policy. However the
      TTL policy is still not fixed by this commit. The TTL policy will be
      fixed in a successive commit.
      
      This is an initial (partial because of TTL policy) fix for issue #2647.
      e423f76e
  15. 12 Jul, 2016 1 commit
  16. 06 Jul, 2016 1 commit
  17. 01 Jul, 2016 1 commit
  18. 30 Jun, 2016 1 commit
    • antirez's avatar
      In Redis RDB check: initial POC. · e97fadb0
      antirez authored
      So far we used an external program (later executed within Redis) and
      parser in order to check RDB files for correctness. This forces, at each
      RDB format update, to have two copies of the same format implementation
      that are hard to keep in sync. Morover the former RDB checker only
      checked the very high-level format of the file, without actually trying
      to load things in memory. Certain corruptions can only be handled by
      really loading key-value pairs.
      
      This first commit attempts to unify the Redis RDB loadig code with the
      task of checking the RDB file for correctness. More work is needed but
      it looks like a sounding direction so far.
      e97fadb0
  19. 16 Jun, 2016 1 commit
  20. 14 Jun, 2016 1 commit
  21. 08 Jun, 2016 1 commit
  22. 05 Jun, 2016 1 commit
  23. 28 May, 2016 1 commit
    • Itamar Haber's avatar
      Allow SPOP from Lua scripts · 2866e023
      Itamar Haber authored
      The existing `R` flag appears to be sufficient and there's no apparent reason why the command should be blocked.
      2866e023
  24. 10 May, 2016 2 commits
  25. 09 May, 2016 1 commit
  26. 05 May, 2016 5 commits
  27. 04 May, 2016 3 commits
  28. 22 Apr, 2016 1 commit
    • therealbill's avatar
      fix for #3187 · 14086a46
      therealbill authored
      I've renamed maxmemoryToString to evictPolicyToString since that is
      more accurate (and easier to mentally connect with the correct data), as
      well as updated the function to user server.maxmemory_policy rather than
      server.maxmemory. Now with a default config it is actually returning
      the correct policy rather than volatile-lru.
      14086a46