You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2017/11/01 20:42:33 UTC

[GitHub] wohali closed pull request #192: Clean up wording in "Add, then delete" section

wohali closed pull request #192: Clean up wording in "Add, then delete" section
URL: https://github.com/apache/couchdb-documentation/pull/192
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/src/cluster/sharding.rst b/src/cluster/sharding.rst
index b2ef4ea..5ad998a 100644
--- a/src/cluster/sharding.rst
+++ b/src/cluster/sharding.rst
@@ -198,19 +198,25 @@ Moving Shards
 Add, then delete
 ----------------
 
-In the world of CouchDB there is no such thing as moving. You can add a new
-replica to a shard and then remove the old replica, thereby creating the
-illusion of moving. If you try to uphold this illusion with a database that have
-``n=1``, you might find yourself in the following scenario:
-
-#. Copy the shard to a new node.
+In the world of CouchDB there is no such thing as "moving" shards, only adding
+and removing shard replicas.
+You can add a new replica of a shard and then remove the old replica,
+thereby creating the illusion of moving.
+If you do this for a database that has ``n=1``,
+you might be caught by the following mistake:
+
+#. Copy the shard onto a new node.
 #. Update the metadata to use the new node.
 #. Delete the shard on the old node.
-#. Lose all writes made between 1 and 2.
-
-As the reality "I added a new replica of the shard X on node Y and then I waited
-for them to sync, before I removed the replica of shard X from node Z." is a bit
-tedious, people and this documentation tend to use the illusion of moving.
+#. Oh, no!: You have lost all writes made between 1 and 2.
+
+To avoid this mistake, you always want to make sure
+that both shards have been live for some time
+and that the shard on your new node is fully caught up
+before removing a shard on an old node.
+Since "moving" is a more conceptually (if not technically)
+accurate description of what you want to do,
+we'll use that word in this documentation as well.
 
 Moving
 ------


 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services