mirror of
https://github.com/etcd-io/etcd.git
synced 2024-09-27 06:25:44 +00:00
Documentation: specify starting revision (#11559)
This commit is contained in:
@@ -10,7 +10,7 @@ etcd stores data in a multiversion [persistent][persistent-ds] key-value store.
|
||||
|
||||
The store’s logical view is a flat binary key space. The key space has a lexically sorted index on byte string keys so range queries are inexpensive.
|
||||
|
||||
The key space maintains multiple **revisions**. Each atomic mutative operation (e.g., a transaction operation may contain multiple operations) creates a new revision on the key space. All data held by previous revisions remains unchanged. Old versions of key can still be accessed through previous revisions. Likewise, revisions are indexed as well; ranging over revisions with watchers is efficient. If the store is compacted to save space, revisions before the compact revision will be removed. Revisions are monotonically increasing over the lifetime of a cluster.
|
||||
The key space maintains multiple **revisions**. When the store is created, the initial revision is 1. Each atomic mutative operation (e.g., a transaction operation may contain multiple operations) creates a new revision on the key space. All data held by previous revisions remains unchanged. Old versions of key can still be accessed through previous revisions. Likewise, revisions are indexed as well; ranging over revisions with watchers is efficient. If the store is compacted to save space, revisions before the compact revision will be removed. Revisions are monotonically increasing over the lifetime of a cluster.
|
||||
|
||||
A key's life spans a generation, from creation to deletion. Each key may have one or multiple generations. Creating a key increments the **version** of that key, starting at 1 if the key does not exist at the current revision. Deleting a key generates a key tombstone, concluding the key’s current generation by resetting its version to 0. Each modification of a key increments its version; so, versions are monotonically increasing within a key's generation. Once a compaction happens, any generation ended before the compaction revision will be removed, and values set before the compaction revision except the latest one will be removed.
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ The number of active members needed for consensus to modify the cluster state. e
|
||||
|
||||
## Revision
|
||||
|
||||
A 64-bit cluster-wide counter that is incremented each time the keyspace is modified.
|
||||
A 64-bit cluster-wide counter that starts at 1 and is incremented each time the keyspace is modified.
|
||||
|
||||
## Role
|
||||
|
||||
|
||||
@@ -48,6 +48,8 @@ type Watcher interface {
|
||||
// through the returned channel. If revisions waiting to be sent over the
|
||||
// watch are compacted, then the watch will be canceled by the server, the
|
||||
// client will post a compacted error watch response, and the channel will close.
|
||||
// If the requested revision is 0 or unspecified, the returned channel will
|
||||
// return watch events that happen after the server receives the watch request.
|
||||
// If the context "ctx" is canceled or timed out, returned "WatchChan" is closed,
|
||||
// and "WatchResponse" from this closed channel has zero events and nil "Err()".
|
||||
// The context "ctx" MUST be canceled, as soon as watcher is no longer being used,
|
||||
|
||||
Reference in New Issue
Block a user