Mirroristas/etcd
2
0
Fork 0
mirror of https://github.com/etcd-io/etcd.git synced 2024-09-27 06:25:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2113 from yichengq/306

Browse Source 
*: remove consistent-get related stuffs
This commit is contained in:
Yicheng Qin 2015-01-16 10:46:56 -08:00
commit 4735324403
3 changed files with 1 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
Documentation/api.md
View File

@ -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.

7
etcdctl/README.md
View File

@ -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:
```

9
etcdctl/command/get_command.go
View File

@ -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)
}