Browse Source

*: remove consistent-get related stuffs

Yicheng Qin 11 years ago
parent
commit
37dde76cd5
3 changed files with 1 additions and 37 deletions
  1. 1 21
      Documentation/api.md
  2. 0 7
      etcdctl/README.md
  3. 0 9
      etcdctl/command/get_command.go

+ 1 - 21
Documentation/api.md

@@ -439,7 +439,7 @@ curl http://127.0.0.1:2379/v2/keys/dir -XPUT -d ttl=30 -d dir=true -d prevExist=
 Keys that are under this directory work as usual, but when the directory expires, a watcher on a key under the directory will get an expire event:
 
 ```sh
-curl 'http://127.0.0.1:2379/v2/keys/dir/asdf?consistent=true&wait=true'
+curl 'http://127.0.0.1:2379/v2/keys/dir/asdf?wait=true'
 ```
 
 ```json
@@ -890,26 +890,6 @@ curl http://127.0.0.1:2379/v2/keys/afile -XPUT --data-urlencode value@afile.txt
 }
 ```
 
-### Read Consistency
-
-#### Read from the Master
-
-Followers in a cluster can be behind the leader in their copy of the keyspace.
-If your application wants or needs the most up-to-date version of a key then it should ensure it reads from the current leader.
-By using the `consistent=true` flag in your GET requests, etcd will make sure you are talking to the current master.
-
-As an example of how a member can be behind the leader let's start with a three member cluster: L, F1, and F2.
-A client makes a write to L and F1 acknowledges the request.
-The client is told the write was successful and the keyspace is updated.
-Meanwhile F2 has partitioned from the network and will have an out-of-date version of the keyspace until the partition resolves.
-Since F2 missed the most recent write, a client reading from F2 will have an out-of-date version of the keyspace.
-
-Implementation notes on `consistent=true`: If the leader you are talking to is
-partitioned it will be unable to determine if it is not currently the master.
-In a later version we will provide a mechanism to set an upperbound of time
-that the current master can be unable to contact the quorom and still serve
-reads.
-
 ### Read Linearization
 
 If you want a read that is fully linearized you can use a `quorum=true` GET.

+ 0 - 7
etcdctl/README.md

@@ -83,13 +83,6 @@ $ etcdctl get /foo/bar
 Hello world
 ```
 
-Get the current value for a key within the cluster:
-
-```
-$ etcdctl get /foo/bar --consistent
-Hello world
-```
-
 Get the value of a key with additional metadata in a parseable format:
 
 ```

+ 0 - 9
etcdctl/command/get_command.go

@@ -32,7 +32,6 @@ func NewGetCommand() cli.Command {
 		Usage: "retrieve the value of a key",
 		Flags: []cli.Flag{
 			cli.BoolFlag{Name: "sort", Usage: "returns result in sorted order"},
-			cli.BoolFlag{Name: "consistent", Usage: "send request to the leader, thereby guranteeing that any earlier writes will be seen by the read"},
 		},
 		Action: func(c *cli.Context) {
 			handleGet(c, getCommandFunc)
@@ -61,16 +60,8 @@ func getCommandFunc(c *cli.Context, client *etcd.Client) (*etcd.Response, error)
 		return nil, errors.New("Key required")
 	}
 	key := c.Args()[0]
-	consistent := c.Bool("consistent")
 	sorted := c.Bool("sort")
 
-	// Setup consistency on the client.
-	if consistent {
-		client.SetConsistency(etcd.STRONG_CONSISTENCY)
-	} else {
-		client.SetConsistency(etcd.WEAK_CONSISTENCY)
-	}
-
 	// Retrieve the value from the server.
 	return client.Get(key, sorted, false)
 }