Entwicklerhandbuch

• 1: Protokoll des Discovery-Dienstes
• 2: Einen lokalen Cluster einrichten
• 3: Mit etcd arbeiten
• 4: Warum ein gRPC-Gateway
• 5: gRPC-Namensauflösung und Discovery
• 6: etcd in eine Go-Anwendung einbetten
• 7: Systemgrenzen
• 8: etcd-Funktionen
• 9: API-Referenz
• 10: API-Referenz: Nebenläufigkeit

1 - Protokoll des Discovery-Dienstes

Das Protokoll des Discovery-Dienstes hilft einem neuen etcd-Mitglied, während der Clusterinitialisierung alle anderen Mitglieder über eine gemeinsame Discovery-URL zu finden.

Das Protokoll des Discovery-Dienstes wird nur während der Clusterinitialisierung verwendet. Es kann nicht zur Neukonfiguration im laufenden Betrieb oder zur Clusterüberwachung genutzt werden.

Das Protokoll verwendet ein neues Discovery-Token, um einen eindeutigen etcd-Cluster zu initialisieren. Ein Discovery-Token kann nur einen etcd-Cluster repräsentieren. Sobald das Discovery-Protokoll mit diesem Token startet, darf es nicht zur Initialisierung eines anderen etcd-Clusters verwendet werden, auch wenn der Vorgang auf halbem Weg fehlschlägt.

Der Rest dieses Artikels erläutert den Discovery-Ablauf anhand von Beispielen für einen selbst betriebenen Discovery-Cluster. Der öffentliche Discovery-Dienst discovery.etcd.io funktioniert ebenso, bietet jedoch eine zusätzliche Schicht, die unübersichtliche URLs verbirgt, UUIDs automatisch erzeugt und einen gewissen Schutz vor übermäßig vielen Anfragen bietet. Im Kern verwendet auch der öffentliche Discovery-Dienst einen etcd-Cluster als Datenspeicher, wie in diesem Dokument beschrieben.

Protokollablauf

Das Discovery-Protokoll nutzt einen internen etcd-Cluster, um die Initialisierung eines neuen Clusters zu koordinieren. Zuerst kommunizieren alle neuen Mitglieder mit dem Discovery-Dienst und helfen dabei, die erwartete Mitgliederliste zu erstellen. Anschließend initialisiert jedes neue Mitglied seinen Server anhand dieser Liste. Sie erfüllt dieselbe Funktion wie die Option -initial-cluster.

Im folgenden Beispielablauf wird jeder Protokollschritt zur Veranschaulichung im curl-Format dargestellt.

Das etcd-Discovery-Protokoll verwendet vereinbarungsgemäß das Schlüsselpräfix _etcd/registry. Wenn unter http://example.com ein etcd-Cluster für den Discovery-Dienst läuft, lautet die vollständige URL zum Discovery-Schlüsselraum http://example.com/v2/keys/_etcd/registry. Sie wird im Beispiel als URL-Präfix verwendet.

Ein neues Discovery-Token erstellen

Ein eindeutiges Token erzeugen, das den neuen Cluster identifiziert. In den folgenden Schritten dient es als eindeutiges Präfix im Discovery-Schlüsselraum. Mit uuidgen lässt es sich einfach erzeugen:

UUID=$(uuidgen)

Die erwartete Clustergröße angeben

Für das Discovery-Token muss eine Clustergröße angegeben werden. Anhand dieser Größe erkennt der Discovery-Dienst, wann er alle Mitglieder gefunden hat, die den Cluster anfänglich bilden sollen.

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size -d value=${cluster_size}

Üblicherweise beträgt die Clustergröße 3, 5 oder 7. Weitere Einzelheiten enthält der Abschnitt zur optimalen Clustergröße .

etcd-Prozesse starten

Die Discovery-URL mit der Option -discovery angeben und die etcd-Prozesse starten. Jeder etcd-Prozess führt intern die folgenden Schritte aus, wenn die Option -discovery angegeben ist.

Selbstregistrierung

Zuerst registriert sich der etcd-Prozess unter der Discovery-URL als Mitglied. Dazu legt er die Mitglieds-ID als Schlüssel unter der Discovery-URL an.

curl -X PUT http://example.com/v2/keys/_etcd/registry/${UUID}/${member_id}?prevExist=false -d value="${member_name}=${member_peer_url_1}&${member_name}=${member_peer_url_2}"

Status prüfen

Er prüft die erwartete Clustergröße und den Registrierungsstatus unter der Discovery-URL und entscheidet dann über den nächsten Schritt.

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}/_config/size
curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}

Wenn noch nicht genügend Mitglieder registriert sind, wartet er auf die übrigen Mitglieder.

Wenn die Anzahl registrierter Mitglieder die erwartete Größe N übersteigt, gelten die ersten N registrierten Mitglieder als Mitgliederliste des Clusters. Ist das Mitglied selbst in dieser Liste enthalten, ist der Discovery-Vorgang erfolgreich, und es ermittelt alle Peers anhand der Mitgliederliste. Ist es nicht enthalten, endet der Discovery-Vorgang mit der Fehlermeldung, dass der Cluster bereits voll ist.

In der etcd-Implementierung kann das Mitglied den Clusterstatus bereits vor seiner Registrierung prüfen. So kann es frühzeitig mit einem Fehler abbrechen, wenn der Cluster bereits voll ist.

Auf alle Mitglieder warten

Der Wartevorgang ist in der etcd-API-Dokumentation ausführlich beschrieben.

curl -X GET http://example.com/v2/keys/_etcd/registry/${UUID}?wait=true&waitIndex=${current_etcd_index}

Er wartet, bis alle Mitglieder gefunden sind.

Öffentlicher Discovery-Dienst

CoreOS Inc. betreibt unter https://discovery.etcd.io/ einen öffentlichen Discovery-Dienst mit einigen Funktionen, die die Nutzung erleichtern.

Schlüsselpräfix verbergen

Der öffentliche Discovery-Dienst leitet https://discovery.etcd.io/${UUID} zum dahinterliegenden etcd-Cluster auf den Schlüssel unter /v2/keys/_etcd/registry um. Er verbirgt das Registrierungsschlüsselpräfix, damit die Discovery-URL kurz und lesbar bleibt.

Neues Token abrufen

GET /new

Sent query:
	size=${cluster_size}
Possible status codes:
	200 OK
	400 Bad Request
200 Body:
	generated discovery url

Der Erzeugungsvorgang im Dienst folgt den Schritten von Ein neues Discovery-Token erstellen bis Die erwartete Clustergröße angeben .

Discovery-Status prüfen

GET /${UUID}

Der Status dieses Discovery-Tokens einschließlich der registrierten Rechner lässt sich durch Abfragen des Werts der UUID prüfen.

Open-Source-Repository

Das Repository befindet sich unter https://github.com/coreos/discovery.etcd.io . Damit lässt sich ein eigener Discovery-Dienst erstellen.

2 - Einen lokalen Cluster einrichten

Für Test- und Entwicklungsumgebungen ist die Konfiguration eines lokalen Clusters der schnellste und einfachste Weg. Für eine produktive Bereitstellung siehe den Abschnitt Cluster einrichten .

Lokaler eigenständiger Cluster

Einen Cluster starten

Mit folgendem Befehl wird ein eigenständiger etcd-Cluster bereitgestellt:

$ ./etcd
...

Wenn die Binärdatei etcd nicht im aktuellen Arbeitsverzeichnis liegt, befindet sie sich möglicherweise unter $GOPATH/bin/etcd oder /usr/local/bin/etcd. Den Befehl entsprechend ausführen.

Das laufende etcd-Mitglied nimmt unter localhost:2379 Client-Anfragen entgegen.

Mit dem Cluster arbeiten

Mit etcdctl lässt sich mit dem laufenden Cluster arbeiten:

1. Ein beispielhaftes Schlüssel-Wert-Paar im Cluster speichern:

     $ ./etcdctl put foo bar
     OK

   Wenn OK ausgegeben wird, wurde das Schlüssel-Wert-Paar erfolgreich gespeichert.

2. Den Wert von foo abrufen:

   $ ./etcdctl get foo
   bar

   Wenn bar zurückgegeben wird, funktioniert die Interaktion mit dem etcd-Cluster wie erwartet.

Lokaler Cluster mit mehreren Mitgliedern

Einen Cluster starten

Im Stammverzeichnis des etcd-Git-Repositorys liegt eine Procfile, mit der sich ein lokaler Cluster mit mehreren Mitgliedern einfach konfigurieren lässt. Zum Starten eines solchen Clusters in das Stammverzeichnis des etcd-Quellbaums wechseln und Folgendes ausführen:

1. goreman installieren, um auf Procfile basierende Anwendungen zu steuern:

   $ go install github.com/mattn/goreman@latest

2. Einen Cluster mit goreman und der mitgelieferten Procfile von etcd starten:

   $ goreman -f Procfile start

   Die Mitglieder starten. Sie nehmen Client-Anfragen unter localhost:2379, localhost:22379 beziehungsweise localhost:32379 entgegen.

Mit dem Cluster arbeiten

Mit etcdctl lässt sich mit dem laufenden Cluster arbeiten:

1. Die Mitgliederliste ausgeben:

   $ etcdctl --write-out=table --endpoints=localhost:2379 member list

   Die Liste der etcd-Mitglieder wird wie folgt angezeigt:

   +------------------+---------+--------+------------------------+------------------------+
   |        ID        | STATUS  |  NAME  |       PEER ADDRS       |      CLIENT ADDRS      |
   +------------------+---------+--------+------------------------+------------------------+
   | 8211f1d0f64f3269 | started | infra1 | http://127.0.0.1:2380  | http://127.0.0.1:2379  |
   | 91bc3c398fb3c146 | started | infra2 | http://127.0.0.1:22380 | http://127.0.0.1:22379 |
   | fd422379fda50e48 | started | infra3 | http://127.0.0.1:32380 | http://127.0.0.1:32379 |
   +------------------+---------+--------+------------------------+------------------------+

2. Ein beispielhaftes Schlüssel-Wert-Paar im Cluster speichern:

   $ etcdctl put foo bar
   OK

   Wenn OK ausgegeben wird, wurde das Schlüssel-Wert-Paar erfolgreich gespeichert.

Fehlertoleranz testen

Um die Fehlertoleranz von etcd zu testen, ein Mitglied beenden und versuchen, den Schlüssel abzurufen.

1. Den Prozessnamen des Mitglieds ermitteln, das angehalten werden soll.

   Die Procfile enthält die Eigenschaften des Clusters mit mehreren Mitgliedern. Als Beispiel dient das Mitglied mit dem Prozessnamen etcd2.

2. Das Mitglied anhalten:

   # kill etcd2
   $ goreman run stop etcd2

3. Einen Schlüssel speichern:

   $ etcdctl put key hello
   OK

4. Den im vorherigen Schritt gespeicherten Schlüssel abrufen:

   $ etcdctl get key
   hello

5. Einen Schlüssel vom angehaltenen Mitglied abrufen:

   $ etcdctl --endpoints=localhost:22379 get key

   Der Befehl sollte wegen der fehlgeschlagenen Verbindung eine Fehlermeldung anzeigen:

   2017/06/18 23:07:35 grpc: Conn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 127.0.0.1:22379: getsockopt: connection refused"; Reconnecting to "localhost:22379"
   Error:  grpc: timed out trying to connect

6. Das angehaltene Mitglied neu starten:

   $ goreman run restart etcd2

7. Den Schlüssel vom neu gestarteten Mitglied abrufen:

   $ etcdctl --endpoints=localhost:22379 get key
   hello

   Der Neustart des Mitglieds stellt die Verbindung wieder her. etcdctl kann den Schlüssel nun erfolgreich abrufen. Weitere Informationen zur Arbeit mit etcd enthält der Abschnitt Mit etcd arbeiten .

3 - Mit etcd arbeiten

Benutzer arbeiten mit etcd meist, indem sie den Wert eines Schlüssels schreiben oder lesen. Dieser Abschnitt beschreibt dies anhand von etcdctl, einem Befehlszeilenwerkzeug zur Interaktion mit dem etcd-Server. Die erläuterten Konzepte sollten auch für die gRPC-APIs und die APIs der Client-Bibliotheken gelten.

etcdctl v3.7 verwendet die v3-API. Die v2-API und die Versionsauswahl über ETCDCTL_API wurden entfernt.

Versionen ermitteln

Die etcdctl-Version und die API-Version des Servers helfen dabei, die passenden Befehle für verschiedene etcd-Operationen zu bestimmen.

Mit folgendem Befehl lassen sich die Versionen ermitteln:

$ etcdctl version
etcdctl version: 3.1.0-alpha.0+git
API version: 3.1

Einen Schlüssel schreiben

Anwendungen speichern Schlüssel im etcd-Cluster, indem sie Werte unter diesen Schlüsseln schreiben. Jeder gespeicherte Schlüssel wird über das Raft-Protokoll auf alle Mitglieder des etcd-Clusters repliziert, um Konsistenz und Zuverlässigkeit zu gewährleisten.

Mit folgendem Befehl wird der Wert des Schlüssels foo auf bar gesetzt:

$ etcdctl put foo bar
OK

Ein Schlüssel kann durch Zuordnen einer Lease auch für einen festgelegten Zeitraum gesetzt werden.

Mit folgendem Befehl wird der Wert des Schlüssels foo1 für 10s auf bar1 gesetzt.

$ etcdctl put foo1 bar1 --lease=1234abcd
OK

Schlüssel lesen

Anwendungen können Schlüsselwerte aus einem etcd-Cluster lesen. Abfragen können einen einzelnen Schlüssel oder einen Schlüsselbereich lesen.

Angenommen, im etcd-Cluster sind folgende Schlüssel gespeichert:

foo = bar
foo1 = bar1
foo2 = bar2
foo3 = bar3

Mit folgendem Befehl wird der Wert des Schlüssels foo gelesen:

$ etcdctl get foo
foo
bar

Mit folgendem Befehl wird der Wert des Schlüssels foo im Hexadezimalformat gelesen:

$ etcdctl get foo --hex
\x66\x6f\x6f          # Key
\x62\x61\x72          # Value

Mit folgendem Befehl wird nur der Wert des Schlüssels foo gelesen:

$ etcdctl get foo --print-value-only
bar

Mit folgendem Befehl werden die Schlüssel von foo bis foo3 abgefragt:

$ etcdctl get foo foo3
foo
bar
foo1
bar1
foo2
bar2

Mit folgendem Befehl werden alle Schlüssel mit dem Präfix foo abgefragt:

$ etcdctl get --prefix foo
foo
bar
foo1
bar1
foo2
bar2
foo3
bar3

Mit folgendem Befehl werden alle Schlüssel mit dem Präfix foo abgefragt und die Ergebnisse auf 2 begrenzt:

$ etcdctl get --prefix --limit=2 foo
foo
bar
foo1
bar1

Mit folgendem Befehl werden alle Schlüssel mit dem Präfix foo über den RPC RangeStream abgefragt. Das Ergebnis ist mit dem eines unären Range-Aufrufs identisch:

$ etcdctl get --stream --prefix foo
foo
bar
foo1
bar1
foo2
bar2
foo3
bar3

--stream unterstützt weder --order noch --sort-by noch Revisionsfilter.

Frühere Schlüsselversionen lesen

Anwendungen möchten möglicherweise ersetzte Versionen eines Schlüssels lesen. Beispielsweise kann eine Anwendung durch Zugriff auf eine frühere Schlüsselversion zu einer alten Konfiguration zurückkehren. Oder sie kann durch den Schlüsselverlauf über mehrere Anfragen hinweg eine konsistente Sicht auf mehrere Schlüssel erhalten. Da jede Änderung am Schlüssel-Wert-Speicher des etcd-Clusters dessen globale Revision erhöht, kann eine Anwendung ersetzte Schlüssel durch Angabe einer älteren etcd-Revision lesen.

Angenommen, im etcd-Cluster sind bereits folgende Schlüssel gespeichert:

foo = bar         # revision = 2
foo1 = bar1       # revision = 3
foo = bar_new     # revision = 4
foo1 = bar1_new   # revision = 5

Das folgende Beispiel zeigt den Zugriff auf frühere Schlüsselversionen:

$ etcdctl get --prefix foo # access the most recent versions of keys
foo
bar_new
foo1
bar1_new

$ etcdctl get --prefix --rev=4 foo # access the versions of keys at revision 4
foo
bar_new
foo1
bar1

$ etcdctl get --prefix --rev=3 foo # access the versions of keys at revision 3
foo
bar
foo1
bar1

$ etcdctl get --prefix --rev=2 foo # access the versions of keys at revision 2
foo
bar

$ etcdctl get --prefix --rev=1 foo # access the versions of keys at revision 1

Schlüssel lesen, deren Bytewert größer oder gleich dem angegebenen Schlüssel ist

Anwendungen möchten möglicherweise Schlüssel lesen, deren Bytewert größer oder gleich dem des angegebenen Schlüssels ist.

Angenommen, im etcd-Cluster sind bereits folgende Schlüssel gespeichert:

a = 123
b = 456
z = 789

Mit folgendem Befehl werden Schlüssel gelesen, deren Bytewert größer oder gleich dem des Schlüssels b ist:

$ etcdctl get --from-key b
b
456
z
789

Schlüssel löschen

Anwendungen können einen einzelnen Schlüssel oder einen Schlüsselbereich aus einem etcd-Cluster löschen.

Angenommen, im etcd-Cluster sind bereits folgende Schlüssel gespeichert:

foo = bar
foo1 = bar1
foo3 = bar3
zoo = val
zoo1 = val1
zoo2 = val2
a = 123
b = 456
z = 789

Mit folgendem Befehl wird der Schlüssel foo gelöscht:

$ etcdctl del foo
1 # one key is deleted

Mit folgendem Befehl werden die Schlüssel von foo bis foo9 gelöscht:

$ etcdctl del foo foo9
2 # two keys are deleted

Mit folgendem Befehl wird der Schlüssel zoo gelöscht und das gelöschte Schlüssel-Wert-Paar zurückgegeben:

$ etcdctl del --prev-kv zoo
1   # one key is deleted
zoo # deleted key
val # the value of the deleted key

Mit folgendem Befehl werden Schlüssel mit dem Präfix zoo gelöscht:

$ etcdctl del --prefix zoo
2 # two keys are deleted

Mit folgendem Befehl werden Schlüssel gelöscht, deren Bytewert größer oder gleich dem des Schlüssels b ist:

$ etcdctl del --from-key b
2 # two keys are deleted

Schlüsseländerungen beobachten

Anwendungen können einen Schlüssel oder einen Schlüsselbereich beobachten, um sämtliche Aktualisierungen zu überwachen.

Mit folgendem Befehl wird der Schlüssel foo beobachtet:

$ etcdctl watch foo
# in another terminal: etcdctl put foo bar
PUT
foo
bar

Mit folgendem Befehl wird der Schlüssel foo im Hexadezimalformat beobachtet:

$ etcdctl watch foo --hex
# in another terminal: etcdctl put foo bar
PUT
\x66\x6f\x6f          # Key
\x62\x61\x72          # Value

Mit folgendem Befehl wird der Schlüsselbereich von foo bis foo9 beobachtet:

$ etcdctl watch foo foo9
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put foo1 bar1
PUT
foo1
bar1

Mit folgendem Befehl werden Schlüssel mit dem Präfix foo beobachtet:

$ etcdctl watch --prefix foo
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put fooz1 barz1
PUT
fooz1
barz1

Mit folgendem Befehl werden die beiden Schlüssel foo und zoo beobachtet:

$ etcdctl watch -i
$ watch foo
$ watch zoo
# in another terminal: etcdctl put foo bar
PUT
foo
bar
# in another terminal: etcdctl put zoo val
PUT
zoo
val

Historische Schlüsseländerungen beobachten

Anwendungen möchten möglicherweise historische Änderungen an Schlüsseln in etcd beobachten. Beispielsweise kann eine Anwendung alle Änderungen eines Schlüssels empfangen wollen. Solange sie mit etcd verbunden bleibt, genügt dafür watch. Fällt jedoch die Anwendung oder etcd aus, kann während des Ausfalls eine Änderung auftreten, die die Anwendung nicht in Echtzeit empfängt. Um die Zustellung der Aktualisierung zu garantieren, muss die Anwendung historische Schlüsseländerungen beobachten können. Dazu kann sie wie beim Lesen früherer Schlüsselversionen eine historische Revision für einen Watch angeben.

Angenommen, die folgende Folge von Operationen wurde ausgeführt:

$ etcdctl put foo bar         # revision = 2
OK
$ etcdctl put foo1 bar1       # revision = 3
OK
$ etcdctl put foo bar_new     # revision = 4
OK
$ etcdctl put foo1 bar1_new   # revision = 5
OK

Das folgende Beispiel zeigt die Beobachtung historischer Änderungen:

# watch for changes on key `foo` since revision 2
$ etcdctl watch --rev=2 foo
PUT
foo
bar
PUT
foo
bar_new

# watch for changes on key `foo` since revision 3
$ etcdctl watch --rev=3 foo
PUT
foo
bar_new

Das folgende Beispiel beobachtet erst ab der letzten historischen Änderung:

# watch for changes on key `foo` and return last revision value along with modified value
$ etcdctl watch --prev-kv foo
# in another terminal: etcdctl put foo bar_latest
PUT
foo         # key
bar_new     # last value of foo key before modification
foo         # key
bar_latest  # value of foo key after modification

Watch-Fortschritt

Anwendungen möchten möglicherweise den Fortschritt eines Watches prüfen, um die Aktualität seines Streams zu bestimmen. Wird ein Watch beispielsweise zur Aktualisierung eines Caches verwendet, kann es hilfreich sein zu wissen, ob der Cache gegenüber der Revision eines Quorum-Lesezugriffs veraltet ist.

In einer interaktiven Watch-Sitzung kann mit dem Befehl “progress” eine Fortschrittsanfrage gestellt werden. Sie fordert den etcd-Server auf, eine Fortschrittsbenachrichtigung im Watch-Stream zu senden:

$ 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

Kompaktierte Revisionen

Wie erwähnt, bewahrt etcd Revisionen auf, damit Anwendungen frühere Schlüsselversionen lesen können. Damit sich jedoch kein unbegrenzt großer Verlauf ansammelt, ist es wichtig, frühere Revisionen zu kompaktieren. Nach der Kompaktierung entfernt etcd historische Revisionen und gibt Ressourcen für die spätere Nutzung frei. Alle ersetzten Daten mit Revisionen vor der Kompaktierungsrevision sind dann nicht mehr verfügbar.

Mit folgendem Befehl werden die Revisionen kompaktiert:

$ etcdctl compact 5
compacted revision 5

# any revisions before the compacted one are not accessible
$ etcdctl get --rev=4 foo
Error:  rpc error: code = 11 desc = etcdserver: mvcc: required revision has been compacted

$ etcdctl get mykey -w=json
{"header":{"cluster_id":14841639068965178418,"member_id":10276657743932975437,"revision":15,"raft_term":4}}

Leases gewähren

Anwendungen können vom etcd-Cluster Leases für Schlüssel anfordern. Wird ein Schlüssel einer Lease zugeordnet, ist seine Lebensdauer an die der Lease gebunden, die ihrerseits durch eine Time-to-live (TTL) bestimmt wird. Jede Lease hat eine Mindest-TTL, die die Anwendung bei der Anforderung angibt. Ihre tatsächliche TTL ist mindestens so groß wie die Mindest-TTL und wird vom etcd-Cluster gewählt. Sobald sie verstrichen ist, läuft die Lease ab, und alle zugeordneten Schlüssel werden gelöscht.

Mit folgendem Befehl wird eine Lease gewährt:

# grant a lease with 60 second TTL
$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)

# attach key foo to lease 32695410dcc0ca06
$ etcdctl put --lease=32695410dcc0ca06 foo bar
OK

Leases widerrufen

Anwendungen widerrufen Leases anhand ihrer Lease-ID. Dabei werden alle der Lease zugeordneten Schlüssel gelöscht.

Angenommen, die folgende Folge von Operationen wurde ausgeführt:

$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)
$ etcdctl put --lease=32695410dcc0ca06 foo bar
OK

Mit folgendem Befehl wird dieselbe Lease widerrufen:

$ etcdctl lease revoke 32695410dcc0ca06
lease 32695410dcc0ca06 revoked

$ etcdctl get foo
# empty response since foo is deleted due to lease revocation

Leases am Leben halten

Anwendungen können eine Lease am Leben halten, indem sie deren TTL erneuern und so ihren Ablauf verhindern.

Angenommen, die folgende Folge von Operationen wurde ausgeführt:

$ etcdctl lease grant 60
lease 32695410dcc0ca06 granted with TTL(60s)

Mit folgendem Befehl wird dieselbe Lease am Leben gehalten:

$ etcdctl lease keep-alive 32695410dcc0ca06
lease 32695410dcc0ca06 keepalived with TTL(60)
lease 32695410dcc0ca06 keepalived with TTL(60)
lease 32695410dcc0ca06 keepalived with TTL(60)
...

Lease-Informationen abrufen

Anwendungen möchten möglicherweise Informationen über Leases abrufen, um sie zu erneuern oder zu prüfen, ob eine Lease noch existiert oder bereits abgelaufen ist. Sie möchten möglicherweise auch wissen, welchen Schlüsseln eine bestimmte Lease zugeordnet ist.

Angenommen, die folgende Folge von Operationen wurde ausgeführt:

# grant a lease with 500 second TTL
$ etcdctl lease grant 500
lease 694d5765fc71500b granted with TTL(500s)

# attach key zoo1 to lease 694d5765fc71500b
$ etcdctl put zoo1 val1 --lease=694d5765fc71500b
OK

# attach key zoo2 to lease 694d5765fc71500b
$ etcdctl put zoo2 val2 --lease=694d5765fc71500b
OK

Mit folgendem Befehl werden Informationen zur Lease abgerufen:

$ etcdctl lease timetolive 694d5765fc71500b
lease 694d5765fc71500b granted with TTL(500s), remaining(258s)

Mit folgendem Befehl werden Informationen zur Lease einschließlich der ihr zugeordneten Schlüssel abgerufen:

$ etcdctl lease timetolive --keys 694d5765fc71500b
lease 694d5765fc71500b granted with TTL(500s), remaining(132s), attached keys([zoo2 zoo1])

# if the lease has expired or does not exist it will give the below response:
Error:  etcdserver: requested lease not found

4 - Warum ein gRPC-Gateway

etcd v3 verwendet gRPC als Nachrichtenprotokoll. Das etcd-Projekt enthält einen gRPC-basierten Go-Client und das Befehlszeilenwerkzeug etcdctl zur Kommunikation mit einem etcd-Cluster über gRPC. Für Sprachen ohne gRPC-Unterstützung stellt etcd ein JSON-gRPC-Gateway bereit. Dieses Gateway dient als RESTful-Proxy, der HTTP/JSON-Anfragen in gRPC-Nachrichten übersetzt.

Das gRPC-Gateway verwenden

Das Gateway akzeptiert eine JSON-Abbildung der Protocol-Buffer -Nachrichtendefinitionen von etcd. Die Felder key und value sind als Byte-Arrays definiert und müssen deshalb in JSON base64-kodiert sein. Die folgenden Beispiele verwenden curl, jeder andere HTTP/JSON-Client sollte jedoch ebenso funktionieren.

Hinweise

Der Endpunkt des gRPC-Gateways hat sich seit etcd v3.3 geändert:

• etcd v3.2 und frühere Versionen verwenden ausschließlich [CLIENT-URL]/v3alpha/*.
• etcd v3.3 verwendet [CLIENT-URL]/v3beta/* und behält [CLIENT-URL]/v3alpha/* bei.
• etcd v3.4 verwendet [CLIENT-URL]/v3/* und behält [CLIENT-URL]/v3beta/* bei.
  • [CLIENT-URL]/v3alpha/* ist veraltet.
• etcd v3.5 und spätere Versionen verwenden ausschließlich [CLIENT-URL]/v3/*.
  • [CLIENT-URL]/v3beta/* ist veraltet.

Das gRPC-Gateway unterstützt keine Authentifizierung über den TLS Common Name.

Schlüssel schreiben und lesen

Die Dienste /v3/kv/range und /v3/kv/put zum Lesen und Schreiben von Schlüsseln verwenden:

<<COMMENT
https://www.base64encode.org/
foo is 'Zm9v' in Base64
bar is 'YmFy'
COMMENT

curl -L http://localhost:2379/v3/kv/put \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"}}

curl -L http://localhost:2379/v3/kv/range \
  -X POST -d '{"key": "Zm9v"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}

# get all keys prefixed with "foo"
curl -L http://localhost:2379/v3/kv/range \
  -X POST -d '{"key": "Zm9v", "range_end": "Zm9w"}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}

Schlüssel beobachten

Den Dienst /v3/watch zum Beobachten von Schlüsseln verwenden:

curl -N http://localhost:2379/v3/watch \
  -X POST -d '{"create_request": {"key":"Zm9v"} }' &
# {"result":{"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"1","raft_term":"2"},"created":true}}

curl -L http://localhost:2379/v3/kv/put \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}' >/dev/null 2>&1
# {"result":{"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"2"},"events":[{"kv":{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}}]}}

Transaktionen

Eine Transaktion mit /v3/kv/txn ausführen:

# target CREATE
curl -L http://localhost:2379/v3/kv/txn \
  -X POST \
  -d '{"compare":[{"target":"CREATE","key":"Zm9v","createRevision":"2"}],"success":[{"requestPut":{"key":"Zm9v","value":"YmFy"}}]}'
# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"3","raft_term":"2"},"succeeded":true,"responses":[{"response_put":{"header":{"revision":"3"}}}]}

# target VERSION
curl -L http://localhost:2379/v3/kv/txn \
  -X POST \
  -d '{"compare":[{"version":"4","result":"EQUAL","target":"VERSION","key":"Zm9v"}],"success":[{"requestRange":{"key":"Zm9v"}}]}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"6","raft_term":"3"},"succeeded":true,"responses":[{"response_range":{"header":{"revision":"6"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"6","version":"4","value":"YmF6"}],"count":"1"}}]}

Authentifizierung

Die Authentifizierung mit dem Dienst /v3/auth einrichten:

# create root user
curl -L http://localhost:2379/v3/auth/user/add \
  -X POST -d '{"name": "root", "password": "pass"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# create root role
curl -L http://localhost:2379/v3/auth/role/add \
  -X POST -d '{"name": "root"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# grant root role
curl -L http://localhost:2379/v3/auth/user/grant \
  -X POST -d '{"user": "root", "role": "root"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

# enable auth
curl -L http://localhost:2379/v3/auth/enable -X POST -d '{}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}

Mit /v3/auth/authenticate bei etcd authentifizieren, um ein Authentifizierungstoken zu erhalten:

# get the auth token for the root user
curl -L http://localhost:2379/v3/auth/authenticate \
  -X POST -d '{"name": "root", "password": "pass"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"},"token":"sssvIpwfnLAcWAQH.9"}

Den Header Authorization auf das Authentifizierungstoken setzen, um einen Schlüssel mit Authentifizierungsdaten abzurufen:

curl -L http://localhost:2379/v3/kv/put \
  -H 'Authorization: sssvIpwfnLAcWAQH.9' \
  -X POST -d '{"key": "Zm9v", "value": "YmFy"}'
# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"2","raft_term":"2"}}

Fehlerantworten

Das gRPC-Gateway übersetzt den gRPC-Status in HTTP-Statuscodes und einen JSON-Fehlerinhalt. Ab etcd v3.6 änderte die Aktualisierung auf grpc-gateway v2 die Fehlerbehandlung (siehe den Hinweis zur Fehlerbehandlung im v2-Migrationsleitfaden). Das Verhalten des Gateways entspricht nun google.rpc.Status (code, message, details), wie im API-Fehlermodell von Google beschrieben. Ältere grpc-gateway-Versionen enthielten außerdem ein error-Feld auf oberster Ebene. Dieses Feld wird in etcd v3.6 und neueren Versionen nicht unterstützt.

Clients sollten den HTTP-Statuscode als vorrangigen Hinweis auf Erfolg oder Fehlschlag behandeln. Schlägt eine Anfrage fehl, sollten Clients das Feld message als wichtigste Quelle für Fehlerinformationen verwenden und zusätzliche Details zur weiteren Einordnung heranziehen.

Swagger

Generierte Swagger -API-Definitionen stehen unter rpc.swagger.json bereit.

5 - gRPC-Namensauflösung und Discovery

etcd stellt einen gRPC-Resolver für ein alternatives Namenssystem bereit, das Endpunkte aus etcd abruft, um gRPC-Dienste zu finden. Der zugrunde liegende Mechanismus beobachtet Änderungen an Schlüsseln, deren Präfix der Dienstname ist.

Diese Funktion ist experimentell, da sie vom Paket google.golang.org/grpc/resolver abhängt, das in grpc-go noch experimentell ist.

etcd-Discovery mit go-grpc verwenden

Der etcd-Client stellt einen gRPC-Resolver bereit, der gRPC-Endpunkte mit einem etcd-Backend auflöst. Der Resolver wird mit einem etcd-Client initialisiert:

import (
	clientv3 "go.etcd.io/etcd/client/v3"
	etcdnaming "go.etcd.io/etcd/client/v3/naming/resolver"

	"google.golang.org/grpc"
)

...

cli, err := clientv3.NewFromURL("http://localhost:2379")
if err != nil {
    // ...
}
r, err := etcdnaming.NewBuilder(cli)
if err != nil {
    // ...
}
conn, gerr := grpc.NewClient("my-service", grpc.WithResolvers(r), ...)

Dienstendpunkte verwalten

Der etcd-Resolver betrachtet alle Schlüssel unter dem Präfix des Auflösungsziels, gefolgt von einem “/” (z. B. “foo/bar/my-service/”), mit JSON-kodierten Werten (früher go-grpc naming.Update) als mögliche Dienstendpunkte. Durch Anlegen neuer Schlüssel werden Endpunkte zum Dienst hinzugefügt; durch Löschen der Schlüssel werden sie entfernt.

Einen Endpunkt hinzufügen

Neue Endpunkte lassen sich mit etcdctl zum Dienst hinzufügen:

ETCDCTL_API=3 etcdctl put foo/bar/my-service/1.2.3.4 '{"Addr":"1.2.3.4"}'

Die Methode endpoints.Manager des etcd-Clients kann ebenfalls neue Endpunkte mit einem zu Addr passenden Schlüssel registrieren:

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.AddEndpoint(context.TODO(),"foo/bar/my-service/e1", endpoints.Endpoint{Addr:"1.2.3.4"})

Um beim Verbindungsaufbau zu einem Dienst mit mehreren Endpunkten Round-Robin-Lastverteilung zu aktivieren, kann die Verbindung mit dem internen Round-Robin-Load-Balancer von grpc eingerichtet werden:

conn, gerr := grpc.NewClient("etcd:///foo", grpc.WithResolvers(etcdResolver),
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`))

Einen Endpunkt löschen

Hosts lassen sich mit etcdctl aus dem Dienst entfernen:

ETCDCTL_API=3 etcdctl del foo/bar/my-service/1.2.3.4

Die Methode endpoints.Manager des etcd-Clients unterstützt auch das Löschen von Endpunkten:

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.DeleteEndpoint(context.TODO(), "foo/bar/my-service/e1")

Einen Endpunkt mit einer Lease registrieren

Die Registrierung eines Endpunkts mit einer Lease stellt sicher, dass er aus dem Dienst entfernt wird, wenn der Host keinen Keepalive-Heartbeat mehr aufrechterhalten kann, etwa bei einem Ausfall des Rechners:

lease=`ETCDCTL_API=3 etcdctl lease grant 5 | cut -f2 -d' '`
ETCDCTL_API=3 etcdctl put --lease=$lease my-service/1.2.3.4 '{"Addr":"1.2.3.4"}'
ETCDCTL_API=3 etcdctl lease keep-alive $lease

In Go:

em := endpoints.NewManager(client, "foo/bar/my-service")
err := em.AddEndpoint(context.TODO(), "foo/bar/my-service/e1", endpoints.Endpoint{Addr:"1.2.3.4"})

Endpunkte atomar aktualisieren

Um mehrere Endpunkte in einer einzigen Transaktion zu ändern, kann endpoints.Manager direkt verwendet werden:

em := endpoints.NewManager(c, "foo")

err := em.Update(context.TODO(), []*endpoints.UpdateWithOpts{
    endpoints.NewDeleteUpdateOpts("foo/bar/my-service/e1", endpoints.Endpoint{Addr: "1.2.3.4"}),
	endpoints.NewAddUpdateOpts("foo/bar/my-service/e1", endpoints.Endpoint{Addr: "1.2.3.14"})})

6 - etcd in eine Go-Anwendung einbetten

Das Go-Paket embed von etcd bietet eine einfache Möglichkeit, einen etcd-Server direkt in Ihre Anwendung einzubetten.

Weitere Einzelheiten enthält die Dokumentation des Pakets embed .

7 - Systemgrenzen

Maximale Anfragegröße

etcd ist für kleine Schlüssel-Wert-Paare ausgelegt, wie sie für Metadaten typisch sind. Größere Anfragen funktionieren, können jedoch die Latenz anderer Anfragen erhöhen. Standardmäßig beträgt die maximale Größe einer Anfrage 1.5 MiB. Diese Grenze lässt sich über die Option --max-request-bytes des etcd-Servers konfigurieren.

Maximale Speichergröße

Die standardmäßige Speichergrenze beträgt 2 GiB und lässt sich über die Option --quota-backend-bytes konfigurieren. Für normale Umgebungen werden maximal 8 GiB empfohlen. etcd gibt beim Start eine Warnung aus, wenn der konfigurierte Wert diese Größe überschreitet.

8 - etcd-Funktionen

Dieses Dokument gibt einen Überblick über die Funktionen von etcd und das Verfahren, nach dem sie als veraltet eingestuft werden. Wie Funktionen in etcd entwickelt werden, erläutern diese Entwicklungsrichtlinien .

Die Funktionen von etcd werden in drei Stufen eingeteilt: experimentell, stabil und unsicher. Mit etcd --help lässt sich die Liste der Funktionen anzeigen.

Experimentell

Um frühzeitig Rückmeldungen zu erhalten, werden neue Funktionen üblicherweise als experimentelle Funktionen eingeführt. Sie sind am Optionsnamen zu erkennen, der mit --experimental beginnen sollte. Bei der Verwendung einer experimentellen Funktion sind folgende Punkte zu beachten:

• Sie kann Fehler enthalten, da sie noch nicht ausreichend von Benutzern getestet wurde. Nach dem Aktivieren funktioniert sie möglicherweise nicht wie erwartet.
• Sie ist standardmäßig deaktiviert.
• Die Unterstützung einer solchen Funktion kann jederzeit ohne Ankündigung eingestellt werden
  • Sie kann in der nächsten Minor- oder Major-Version entfernt werden, ohne die Richtlinie zur Einstufung als veraltet einzuhalten, sofern sie nicht in die stabile Stufe übergeht.
  • Das Projektteam freut sich über Fehlermeldungen zu experimentellen Funktionen. Diese Probleme können jedoch eine geringere Priorität erhalten als Probleme mit stabilen Funktionen.
• Eine experimentelle Funktionsoption wird als veraltet eingestuft , sobald die Funktion die stabile Stufe erreicht. Benutzer sollten möglichst bald auf die stabile Funktionsoption umsteigen.

Stabil

Dies ist die häufigste Stufe von Funktionen in etcd. Eine stabile Funktion zeichnet sich durch Folgendes aus:

• Sie wird im Rahmen der unterstützten etcd-Versionen unterstützt.
• Sie kann standardmäßig aktiviert sein.
• Die Einstellung der Unterstützung muss der Richtlinie zur Einstufung als veraltet folgen.

Unsicher

Unsichere Funktionen sind selten und werden im Abschnitt Unsafe feature: der etcd-Nutzungsdokumentation aufgeführt. Sie sind standardmäßig deaktiviert. Sie sollten mit Vorsicht und gemäß der Dokumentation verwendet werden. Eine unsichere Funktion kann in der nächsten Minor- oder Major-Version entfernt werden, ohne die Richtlinie zur Einstufung als veraltet einzuhalten.

Funktionen als veraltet einstufen

Experimentell

Eine experimentelle Funktion wird als veraltet eingestuft, sobald sie die stabile Stufe erreicht.

• Die Dokumentation der experimentellen Funktion zeigt einen Hinweis auf die Einstufung als veraltet und empfiehlt die entsprechende stabile Funktionsoption, z. B. DEPRECATED. Use <feature-name> instead.
• Eine als veraltet eingestufte Funktion wird in der darauffolgenden Version entfernt.

Stabil

Im Zuge der Projektentwicklung kann es nötig werden, auch eine stabile Funktion als veraltet einzustufen und zu entfernen. In diesem Fall gilt:

• Die Dokumentation der Funktion zeigt vor der Version, für die die Einstufung als veraltet geplant ist, eine Warnmeldung, z. B. To be deprecated in <release>.. Ist bereits eine neue Funktion als Ersatz für die mit To be deprecated gekennzeichnete Funktion geplant, wird auch darauf hingewiesen, z. B. Use <feature-name> instead..
• Die Funktion wird in der geplanten Version als veraltet eingestuft. Ab dann zeigt ihre Dokumentation einen entsprechenden Hinweis und empfiehlt eine verwandte stabile Funktion, z. B. DEPRECATED. Use <feature-name> instead.
• Eine als veraltet eingestufte Funktion wird in der darauffolgenden Version entfernt.

9 - API-Referenz

Diese API-Referenz wird automatisch aus den angegebenen .proto-Dateien erzeugt.

Dienst Auth (api/etcdserverpb/rpc.proto)

Dienst Cluster (api/etcdserverpb/rpc.proto)

Dienst KV (api/etcdserverpb/rpc.proto)

Dienst Lease (api/etcdserverpb/rpc.proto)

Dienst Maintenance (api/etcdserverpb/rpc.proto)

Dienst Watch (api/etcdserverpb/rpc.proto)

Nachricht AlarmMember (api/etcdserverpb/rpc.proto)

Nachricht AlarmRequest (api/etcdserverpb/rpc.proto)

Nachricht AlarmResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthDisableRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthDisableResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthEnableRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthEnableResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleAddRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleAddResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleDeleteRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleDeleteResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleGetRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleGetResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleGrantPermissionRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleGrantPermissionResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleListRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleListResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleRevokePermissionRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthRoleRevokePermissionResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthStatusRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthStatusResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthUserAddRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthUserAddResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthUserChangePasswordRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthUserChangePasswordResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthUserDeleteRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthUserDeleteResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthUserGetRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthUserGetResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthUserGrantRoleRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthUserGrantRoleResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthUserListRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthUserListResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthUserRevokeRoleRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthUserRevokeRoleResponse (api/etcdserverpb/rpc.proto)

Nachricht AuthenticateRequest (api/etcdserverpb/rpc.proto)

Nachricht AuthenticateResponse (api/etcdserverpb/rpc.proto)

Nachricht CompactionRequest (api/etcdserverpb/rpc.proto)

CompactionRequest kompaktiert den Schlüssel-Wert-Speicher bis zu einer angegebenen Revision. Alle ersetzten Schlüssel mit einer Revision unterhalb der Kompaktierungsrevision werden entfernt.

Nachricht CompactionResponse (api/etcdserverpb/rpc.proto)

Nachricht Compare (api/etcdserverpb/rpc.proto)

Nachricht DefragmentRequest (api/etcdserverpb/rpc.proto)

Nachricht DefragmentResponse (api/etcdserverpb/rpc.proto)

Nachricht DeleteRangeRequest (api/etcdserverpb/rpc.proto)

Nachricht DeleteRangeResponse (api/etcdserverpb/rpc.proto)

Nachricht DowngradeInfo (api/etcdserverpb/rpc.proto)

Nachricht DowngradeRequest (api/etcdserverpb/rpc.proto)

Nachricht DowngradeResponse (api/etcdserverpb/rpc.proto)

Nachricht DowngradeVersionTestRequest (api/etcdserverpb/rpc.proto)

DowngradeVersionTestRequest wird nur für Tests verwendet. Die Version in dieser Anfrage wird als Version des WAL-Eintrags gelesen. Ist die Downgrade-Zielversion kleiner als diese Version, ist das Downgrade im laufenden Betrieb oder die Offline-Migration nicht sicher und sollte daher nicht zugelassen werden.

Nachricht HashKVRequest (api/etcdserverpb/rpc.proto)

Nachricht HashKVResponse (api/etcdserverpb/rpc.proto)

Nachricht HashRequest (api/etcdserverpb/rpc.proto)

Nachricht HashResponse (api/etcdserverpb/rpc.proto)

Nachricht LeaseCheckpoint (api/etcdserverpb/rpc.proto)

Nachricht LeaseCheckpointRequest (api/etcdserverpb/rpc.proto)

Nachricht LeaseCheckpointResponse (api/etcdserverpb/rpc.proto)

Nachricht LeaseGrantRequest (api/etcdserverpb/rpc.proto)

Nachricht LeaseGrantResponse (api/etcdserverpb/rpc.proto)

Nachricht LeaseKeepAliveRequest (api/etcdserverpb/rpc.proto)

Nachricht LeaseKeepAliveResponse (api/etcdserverpb/rpc.proto)

Nachricht LeaseLeasesRequest (api/etcdserverpb/rpc.proto)

Nachricht LeaseLeasesResponse (api/etcdserverpb/rpc.proto)

Nachricht LeaseRevokeRequest (api/etcdserverpb/rpc.proto)

Nachricht LeaseRevokeResponse (api/etcdserverpb/rpc.proto)

Nachricht LeaseStatus (api/etcdserverpb/rpc.proto)

Nachricht LeaseTimeToLiveRequest (api/etcdserverpb/rpc.proto)

Nachricht LeaseTimeToLiveResponse (api/etcdserverpb/rpc.proto)

Nachricht Member (api/etcdserverpb/rpc.proto)

Nachricht MemberAddRequest (api/etcdserverpb/rpc.proto)

Nachricht MemberAddResponse (api/etcdserverpb/rpc.proto)

Nachricht MemberListRequest (api/etcdserverpb/rpc.proto)

Nachricht MemberListResponse (api/etcdserverpb/rpc.proto)

Nachricht MemberPromoteRequest (api/etcdserverpb/rpc.proto)

Nachricht MemberPromoteResponse (api/etcdserverpb/rpc.proto)

Nachricht MemberRemoveRequest (api/etcdserverpb/rpc.proto)

Nachricht MemberRemoveResponse (api/etcdserverpb/rpc.proto)

Nachricht MemberUpdateRequest (api/etcdserverpb/rpc.proto)

Nachricht MemberUpdateResponse (api/etcdserverpb/rpc.proto)

Nachricht MoveLeaderRequest (api/etcdserverpb/rpc.proto)

Nachricht MoveLeaderResponse (api/etcdserverpb/rpc.proto)

Nachricht PutRequest (api/etcdserverpb/rpc.proto)

Nachricht PutResponse (api/etcdserverpb/rpc.proto)

Nachricht RangeRequest (api/etcdserverpb/rpc.proto)

Nachricht RangeResponse (api/etcdserverpb/rpc.proto)

Nachricht RequestOp (api/etcdserverpb/rpc.proto)

Nachricht ResponseHeader (api/etcdserverpb/rpc.proto)

Nachricht ResponseOp (api/etcdserverpb/rpc.proto)

Nachricht SnapshotRequest (api/etcdserverpb/rpc.proto)

Nachricht SnapshotResponse (api/etcdserverpb/rpc.proto)

Nachricht StatusRequest (api/etcdserverpb/rpc.proto)

Nachricht StatusResponse (api/etcdserverpb/rpc.proto)

Nachricht TxnRequest (api/etcdserverpb/rpc.proto)

Aus dem Google-PaxosDB-Papier: Unsere Implementierung beruht auf einer leistungsfähigen Grundoperation namens MultiOp. Alle anderen Datenbankoperationen außer der Iteration sind als einzelner MultiOp-Aufruf implementiert. Eine MultiOp wird atomar angewendet und besteht aus drei Komponenten: 1. Einer Liste von Prüfungen namens guard. Jede Prüfung in guard prüft einen einzelnen Datenbankeintrag. Sie kann prüfen, ob ein Wert fehlt oder vorhanden ist, oder ihn mit einem angegebenen Wert vergleichen. Zwei verschiedene Prüfungen in guard können denselben oder unterschiedliche Datenbankeinträge betreffen. Alle Prüfungen in guard werden ausgeführt, und MultiOp gibt die Ergebnisse zurück. Sind alle Prüfungen wahr, führt MultiOp t op aus (siehe Punkt 2 unten), andernfalls f op (siehe Punkt 3 unten). 2. Einer Liste von Datenbankoperationen namens t op. Jede Operation ist eine Einfüge-, Lösch- oder Suchoperation und betrifft einen einzelnen Datenbankeintrag. Zwei verschiedene Operationen können denselben oder unterschiedliche Datenbankeinträge betreffen. Diese Operationen werden ausgeführt, wenn guard true ergibt. 3. Einer Liste von Datenbankoperationen namens f op. Wie t op, wird jedoch ausgeführt, wenn guard false ergibt.

Nachricht TxnResponse (api/etcdserverpb/rpc.proto)

Nachricht WatchCancelRequest (api/etcdserverpb/rpc.proto)

Nachricht WatchCreateRequest (api/etcdserverpb/rpc.proto)

Nachricht WatchProgressRequest (api/etcdserverpb/rpc.proto)

Fordert an, dass der Fortschrittsstatus eines Watch-Streams so bald wie möglich im Watch-Antwortstream gesendet wird.

Nachricht WatchRequest (api/etcdserverpb/rpc.proto)

Nachricht WatchResponse (api/etcdserverpb/rpc.proto)

Nachricht Event (api/mvccpb/kv.proto)

Nachricht KeyValue (api/mvccpb/kv.proto)

Nachricht Lease (server/lease/leasepb/lease.proto)

Nachricht LeaseInternalRequest (server/lease/leasepb/lease.proto)

Nachricht LeaseInternalResponse (server/lease/leasepb/lease.proto)

Nachricht Permission (api/authpb/auth.proto)

Permission ist eine einzelne Entität

Nachricht Role (api/authpb/auth.proto)

Role ist ein einzelner Eintrag im Bucket authRoles

Nachricht User (api/authpb/auth.proto)

User ist ein einzelner Eintrag im Bucket authUsers

Nachricht UserAddOptions (api/authpb/auth.proto)

10 - API-Referenz: Nebenläufigkeit

Diese API-Referenz wird automatisch aus den angegebenen .proto-Dateien erzeugt.

Dienst Lock (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Der Lock-Dienst stellt clientseitige Sperrfunktionen als gRPC-Schnittstelle bereit.

Nachricht LockRequest (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Nachricht LockResponse (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Nachricht UnlockRequest (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Nachricht UnlockResponse (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Dienst Election (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Der Election-Dienst stellt clientseitige Wahlfunktionen als gRPC-Schnittstelle bereit.

Nachricht CampaignRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht CampaignResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht LeaderKey (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht LeaderRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht LeaderResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht ProclaimRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht ProclaimResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht ResignRequest (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht ResignResponse (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Nachricht Event (api/mvccpb/kv.proto)

Nachricht KeyValue (api/mvccpb/kv.proto)