*: Add progress notify request watch request
This commit is contained in:
@ -740,7 +740,7 @@ Empty field.
|
||||
| ----- | ----------- | ---- |
|
||||
| cluster_id | cluster_id is the ID of the cluster which sent the response. | uint64 |
|
||||
| member_id | member_id is the ID of the member which sent the response. | uint64 |
|
||||
| revision | revision is the key-value store revision when the request was applied. | int64 |
|
||||
| revision | revision is the key-value store revision when the request was applied. For watch progress responses, the header.revision indicates progress. All future events recieved in this stream are guaranteed to have a higher revision number than the header.revision number. | int64 |
|
||||
| raft_term | raft_term is the raft term when the request was applied. | uint64 |
|
||||
|
||||
|
||||
@ -840,6 +840,14 @@ From google paxosdb paper: Our implementation hinges around a powerful primitive
|
||||
|
||||
|
||||
|
||||
##### message `WatchProgressRequest` (etcdserver/etcdserverpb/rpc.proto)
|
||||
|
||||
Requests the a watch stream progress status be sent in the watch response stream as soon as possible.
|
||||
|
||||
Empty field.
|
||||
|
||||
|
||||
|
||||
##### message `WatchRequest` (etcdserver/etcdserverpb/rpc.proto)
|
||||
|
||||
| Field | Description | Type |
|
||||
@ -847,6 +855,7 @@ From google paxosdb paper: Our implementation hinges around a powerful primitive
|
||||
| request_union | request_union is a request to either create a new watcher or cancel an existing watcher. | oneof |
|
||||
| create_request | | WatchCreateRequest |
|
||||
| cancel_request | | WatchCancelRequest |
|
||||
| progress_request | | WatchProgressRequest |
|
||||
|
||||
|
||||
|
||||
|
@ -2195,7 +2195,7 @@
|
||||
"format": "uint64"
|
||||
},
|
||||
"revision": {
|
||||
"description": "revision is the key-value store revision when the request was applied.",
|
||||
"description": "revision is the key-value store revision when the request was applied.\nFor watch progress responses, the header.revision indicates progress. All future events\nrecieved in this stream are guaranteed to have a higher revision number than the\nheader.revision number.",
|
||||
"type": "string",
|
||||
"format": "int64"
|
||||
}
|
||||
@ -2396,6 +2396,10 @@
|
||||
}
|
||||
}
|
||||
},
|
||||
"etcdserverpbWatchProgressRequest": {
|
||||
"description": "Requests the a watch stream progress status be sent in the watch response stream as soon as\npossible.",
|
||||
"type": "object"
|
||||
},
|
||||
"etcdserverpbWatchRequest": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
@ -2404,6 +2408,9 @@
|
||||
},
|
||||
"create_request": {
|
||||
"$ref": "#/definitions/etcdserverpbWatchCreateRequest"
|
||||
},
|
||||
"progress_request": {
|
||||
"$ref": "#/definitions/etcdserverpbWatchProgressRequest"
|
||||
}
|
||||
}
|
||||
},
|
||||
|
@ -168,7 +168,7 @@
|
||||
"revision": {
|
||||
"type": "string",
|
||||
"format": "int64",
|
||||
"description": "revision is the key-value store revision when the request was applied."
|
||||
"description": "revision is the key-value store revision when the request was applied.\nFor watch progress responses, the header.revision indicates progress. All future events\nrecieved in this stream are guaranteed to have a higher revision number than the\nheader.revision number."
|
||||
},
|
||||
"raft_term": {
|
||||
"type": "string",
|
||||
|
@ -87,7 +87,7 @@
|
||||
"revision": {
|
||||
"type": "string",
|
||||
"format": "int64",
|
||||
"description": "revision is the key-value store revision when the request was applied."
|
||||
"description": "revision is the key-value store revision when the request was applied.\nFor watch progress responses, the header.revision indicates progress. All future events\nrecieved in this stream are guaranteed to have a higher revision number than the\nheader.revision number."
|
||||
},
|
||||
"raft_term": {
|
||||
"type": "string",
|
||||
|
@ -355,6 +355,26 @@ foo # key
|
||||
bar_latest # value of foo key after modification
|
||||
```
|
||||
|
||||
## Watch progress
|
||||
|
||||
Applications may want to check the progress of a watch to determine how up-to-date the watch stream is. For example, if a watch is used to update a cache, it can be useful to know if the cache is stale compared to the revision from a quorum read.
|
||||
|
||||
Progress requests can be issued using the "progress" command in interactive watch session to ask the etcd server to send a progress notify update in the watch stream:
|
||||
|
||||
```bash
|
||||
$ etcdctl watch -i
|
||||
$ watch a
|
||||
$ progress
|
||||
progress notify: 1
|
||||
# in another terminal: etcdctl put x 0
|
||||
# in another terminal: etcdctl put y 1
|
||||
$ progress
|
||||
progress notify: 3
|
||||
```
|
||||
|
||||
Note: The revision number in the progress notify response is the revision from the local etcd server node that the watch stream is connected to. If this node is partitioned and not part of quorum, this progress notify revision might be lower than
|
||||
than the revision returned by a quorum read against a non-partitioned etcd server node.
|
||||
|
||||
## Compacted revisions
|
||||
|
||||
As we mentioned, etcd keeps revisions so that applications can read past versions of keys. However, to avoid accumulating an unbounded amount of history, it is important to compact past revisions. After compacting, etcd removes historical revisions, releasing resources for future use. All superseded data with revisions before the compacted revision will be unavailable.
|
||||
|
Reference in New Issue
Block a user