diff options
author | michael-grunder <michael.grunder@gmail.com> | 2013-09-01 06:20:34 +0400 |
---|---|---|
committer | michael-grunder <michael.grunder@gmail.com> | 2013-09-01 06:20:34 +0400 |
commit | eb0bbbafa048d7948c14fbc3957247135c19bff6 (patch) | |
tree | b409d766ee9d021d750c34d748373d3d67b7f647 /arrays.markdown | |
parent | f5fc23cbe2b9036f93a07126a0a591241cbbba70 (diff) |
Rollback the automatic resharding distributor
I accidentally pulled this when getting some of the pull requests
integrated (git flow style) for this release. I like the idea
for sure, but I think it needs more detailed documentation and
further testing.
At the very least, I need to understand it :)
Diffstat (limited to 'arrays.markdown')
-rw-r--r-- | arrays.markdown | 40 |
1 files changed, 0 insertions, 40 deletions
diff --git a/arrays.markdown b/arrays.markdown index 012a8e65..b1220891 100644 --- a/arrays.markdown +++ b/arrays.markdown @@ -88,46 +88,6 @@ In order to control the distribution of keys by hand, you can provide a custom f For instance, instanciate a RedisArray object with `new RedisArray(array("us-host", "uk-host", "de-host"), array("distributor" => "dist"));` and write a function called "dist" that will return `2` for all the keys that should end up on the "de-host" server. -You may also provide an array of 2 values that will be used as follows: -- The first value is the initial amount of shards in use before the resharding (the x first shards specified in the constructor) -- The second value is the resharding level, or number of resharding iterations. - -For instance, suppose you started with 4 shards as follows: -<pre> -0 => 0 1 2 3 -</pre> - -After 1 iteration of resharding, keys will be assigned to the following servers: -<pre> -1 => 0 4 1 5 2 6 3 7 -</pre> - -After 2 iterations, keys will be assigned to the following servers: -<pre> -2 => 0 8 4 12 1 9 5 13 2 10 6 14 3 11 7 15 -</pre> - -After 3 iterations, keys will be assigned to the following servers: -<pre> -3 => 0 16 8 24 4 20 12 28 1 17 9 25 5 21 13 29 2 18 10 26 6 22 14 30 3 19 11 27 7 23 15 31 -</pre> - -And so on... - -The idea here is to be able to reshard the keys easily, without moving keys from 1 server to another. - -The procedure to adopt is simple: - -For each initial shard, setup a slave. For instance, for shard 1 we setup slave 5. - -Keys will now be assigned to either shard 1 or shard 5. Once the application sees the new settings, just setup shard 5 as a master. Then, in order to reclaim memory, just cleanup keys from shard 1 that belong to shard 5 and vice-versa. - -On the next iteration, setup a new slave 9 for shard 1 and a new slave 13 for shard 5. - -Update the application settings, disconnect the new slaves and clean up the shards from keys that don't belong there anymore. - -Apply the same procedure for each resharding iteration. - ### Example <pre> $ra = new RedisArray(array("host1", "host2", "host3", "host4", "host5", "host6", "host7", "host8"), array("distributor" => array(2, 2))); |