Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/phpredis/phpredis.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authormichael-grunder <michael.grunder@gmail.com>2013-09-01 06:20:34 +0400
committermichael-grunder <michael.grunder@gmail.com>2013-09-01 06:20:34 +0400
commiteb0bbbafa048d7948c14fbc3957247135c19bff6 (patch)
treeb409d766ee9d021d750c34d748373d3d67b7f647 /arrays.markdown
parentf5fc23cbe2b9036f93a07126a0a591241cbbba70 (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.markdown40
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)));