1. 25 Jan, 2016 4 commits
  2. 02 Jan, 2016 1 commit
  3. 18 Dec, 2015 6 commits
  4. 13 Dec, 2015 1 commit
    • antirez's avatar
      Cluster: redis-trib: use variadic MIGRATE. · ea897338
      antirez authored
      We use the new variadic/pipelined MIGRATE for faster migration.
      Testing is not easy because to see the time it takes for a slot to be
      migrated requires a very large data set, but even with all the overhead
      of migrating multiple slots and to setup them properly, what used to
      take 4 seconds (1 million keys, 200 slots migrated) is now 1.6 which is
      a good improvement. However the improvement can be a lot larger if:
      
      1. We use large datasets where a single slot has many keys.
      2. By moving more than 10 keys per iteration, making this configurable,
         which is planned.
      
      Close #2710
      Close #2711
      ea897338
  5. 11 Dec, 2015 1 commit
  6. 06 Dec, 2015 1 commit
  7. 15 Oct, 2015 3 commits
  8. 08 Jan, 2015 3 commits
  9. 11 Dec, 2014 1 commit
  10. 31 Oct, 2014 1 commit
  11. 06 Oct, 2014 1 commit
  12. 23 Jul, 2014 2 commits
  13. 23 May, 2014 3 commits
  14. 12 May, 2014 5 commits
  15. 16 Apr, 2014 1 commit
    • antirez's avatar
      Cluster: redis-trib cluster allocation more even across nodes. · 68378639
      antirez authored
      redis-trib used to allocate slots not considering fractions of nodes
      when computing the slots_per_node amount. So the fractional part was
      carried over till the end of the allocation, where the last node
      received a few more slots than any other (or a lot more if the cluster
      was composed of many nodes).
      
      The computation was changed to allocate slots more evenly when they are
      not exactly divisible for the number of masters we have.
      68378639
  16. 24 Mar, 2014 2 commits
    • Matt Stancliff's avatar
      Cluster: Restore proper trib master iteration · 4af72d32
      Matt Stancliff authored
      This got removed in 2e5c394f during a new feature addition.
      
      The prior commit had "break if masters.length == masters_count"
      but we are guaranteed to aready have that condition met since
      otherwise we would haven't gotten this far.
      
      Without this break statement, it's possible some masters may
      be forgotten and have zero replicas while other masters have
      more than their requested number of replicas.
      
      Thanks to carlos for pointing out this regression at:
      https://groups.google.com/forum/#!topic/redis-db/_WVVqDw5B7c
      4af72d32
    • Matt Stancliff's avatar
      Cluster: Fix trib create when masters==replicas · ee18135a
      Matt Stancliff authored
      This bug was introduced in 2e5c394f during a refactor.
      
      It took me a while to understand what was going on with
      the code, so I've refactored it further by:
        - Replacing boolean values with meaningful symbols
        - Replacing 'i' with a meaningful variable name
        - Adding the proper abort check
        - Factoring out now duplicated conditionals
        - Adding optional verbose logging (we're inside *four*
          different looping constructs, so it takes a while to
          figure out where all the moving parts are)
        - Updating comment for the section
      
      This fixes a problem when the number of master instances
      equaled the number of replica instances.  Before, when
      there were equal numbers of both, nodes_count would go to
      zero, but the while loop would spin in i < @replicas because
      i would never be updated (because the nodes_list of each ip
      was length == 0, which triggered an endless loop of
      next -> i = 0 -> 0 < 1? -> true -> next -> i = 0 ...)
      
      Thanks to carlo who found this problem at:
      https://groups.google.com/forum/#!topic/redis-db/_WVVqDw5B7c
      ee18135a
  17. 15 Mar, 2014 1 commit
  18. 11 Mar, 2014 2 commits
  19. 11 Feb, 2014 1 commit