Diese Seite beschreibt Calíope 1.6, die Version, die ich gerade baue. Die 1.5 ist im App Store für Mac, iPad, iPhone, Apple Watch, Apple TV und Apple Vision Pro. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Wie man die Schlüssel eines Redis-Servers durchläuft, liest und bearbeitet.
Wo es zu finden ist: Workspace › Werkzeuge › Schlüssel
Gilt für:Redis
Der Browser zeigt links die Schlüssel der Datenbank, nach Präfix gruppiert, und rechts die Details des gewählten Schlüssels.
Wie die Schlüssel durchlaufen werden
Calíope fragt sie mit SCAN ab, in Portionen, und nie mit KEYS: KEYS durchläuft die ganze Datenbank in einem Zug, und da Redis die Befehle einzeln abarbeitet, antwortet es währenddessen niemandem sonst. Die Fußzeile nennt, wie viele Schlüssel durchlaufen wurden und ob der Durchlauf fertig ist oder noch Schlüssel übrig sind; Weitere Schlüssel laden holt die nächste Portion. In einem Cluster wird jeder Primärknoten durchlaufen, und die Fußzeile nennt, wie viele geantwortet haben; fehlt einer, wird er mit seinem Grund genannt.
Das Feld oben ist ein MATCH-Muster —app:*, *:1001—, keine Suche nach Inhalt, und der Server wendet es an, sobald du aufhörst zu tippen.
Die Gruppen bildet Calíope, nicht der Server
Redis hat keine Ordner: Jeder Schlüssel ist ein flacher Name. Die Gruppen entstehen, indem die Namen am Zeichen aus dem Menü Trennzeichen der Leiste geteilt werden (:, /, ., | oder Keines: flache Liste), und der Server weiß nichts von ihnen. Das Trennzeichen wird pro Sitzung gewählt, und jede Gruppe nennt, wie viele Schlüssel an ihr hängen. Mit der Tastatur durchlaufen die Pfeiltasten die Liste, und → und ← öffnen und schließen die gewählte Gruppe; auf dem iPhone öffnet ein Tippen auf einen Schlüssel seine Details.
Typ und Ablauf
Jeder Schlüssel trägt seinen Typ, mit Symbol und Namen, und seinen Ablauf, der in den Details rückwärts zählt. Kein Ablauf und Existiert nicht mehr sind nicht dasselbe: Das Erste ist ein Schlüssel, der bleibt, bis ihn jemand löscht; das Zweite einer, der abgelaufen ist oder den ein anderer Client gelöscht hat, nachdem er durchlaufen wurde.
Die Details
Unter Schlüssel, Typ und Ablauf stehen die Größe —Länge in Bytes, Felder oder Elemente—, die Interne Kodierung und der Speicher, danach der Wert. Die Größe wird vor dem Inhalt abgefragt: Ein großer Wert wird stückweise gelesen, und eine Taste lädt das nächste Stück. In einer Liste trägt jedes Element seinen Index, weil in Redis die Position Teil der Daten ist; eine Menge weist darauf hin, dass sie keine Reihenfolge hat; eine sortierte Menge zeigt jedes Element neben seiner Punktzahl, vom kleinsten zum größten; und ein Stream zeigt zuerst seine eigenen Daten —erster und letzter Eintrag, zuletzt erzeugte ID, größte gelöschte ID—, dann seine Consumer-Gruppen mit ihren ausstehenden Einträgen und ihrem Rückstand, und zuletzt seine Einträge. Ein Wert, der kein UTF-8 ist, wird hexadezimal gezeigt, und Steuerzeichen werden maskiert.
Was sich bearbeiten lässt
Am gewählten Schlüssel, aus der Leiste und aus dem Kontextmenü der Liste: Ablauf… (oder Ablauf entfernen, wenn der Schlüssel abläuft); Umbenennen…, das warnt, wenn der Name schon existiert, und den anderen Schlüssel nur mit Ersetzen überschreibt; und Schlüssel löschen…, das immer nachfragt und Schlüssel, Typ und Größe nennt. Zu derselben Frage führen die Löschtaste und auf iPhone und iPad das Wischen der Zeile nach links.
Im Wert: Wert bearbeiten… bei einem String, der seinen Ablauf behält; Feld hinzufügen…, Bearbeiten… und Entfernen bei einem Hash; Bearbeiten… einer Position in einer Liste; Element hinzufügen… und Entfernen bei einer Menge; und Element hinzufügen…, Bearbeiten… —das die Punktzahl ändert— und Entfernen bei einer sortierten Menge. Beim Entfernen des letzten Elements erscheint der Hinweis, dass Redis den Schlüssel löscht, sobald er leer ist. Jede Änderung erscheint an Ort und Stelle, ohne die Liste neu zu laden, und bleibt im Protokoll dessen, was Calíope ausgeführt hat.
Ein binärer Wert wird nicht bearbeitet, auch keiner über 64 KiB und kein Stream. Und es gibt weder das Leeren der Datenbank noch das Löschen nach Muster: Es wird ein Schlüssel nach dem anderen gelöscht, und man weiß, welcher.
Mit Calíope 1.4 geöffnete Profile
Ein Redis-Profil, das mit einem Gerät synchronisiert ist, auf dem noch Calíope 1.4 läuft, wird dort als MariaDB am selben Port gelesen, weil diese Version Redis nicht kennt; speicherst du es auf diesem Gerät, wird es auf all deinen Geräten so überschrieben. Es lässt sich wiederherstellen, indem man im Profil erneut Redis wählt: Weder der Server noch das Passwort gehen verloren.
Was das Server-Panel von Redis zeigt und wie jede Zahl zu lesen ist.
Wo es zu finden ist: Workspace › Werkzeuge › Server
Gilt für:Redis
Das Panel zeigt den Zustand des Redis-Servers so, wie INFO ihn veröffentlicht. Es liest sich alle 2 Sekunden selbst neu, solange es sichtbar ist, und Aktualisieren liest es sofort neu. Unter jeder Zahl steht das INFO-Feld, aus dem sie stammt, damit du sie mit redis-cli vergleichen kannst.
Die sechs Karten Belegter Speicher ist used_memory, mit dem Limit (maxmemory) und dem Prozentsatz, oder ohne Limit, wenn maxmemory 0 ist; darunter, was der Server tut, wenn er voll ist, und der Höchststand.
Fragmentierung ist der Speicher, den der Prozess im System belegt, geteilt durch den, den er nutzt. Über 1 belegt der Prozess mehr, als er nutzt: Lücken, die der Speicher-Allocator noch nicht zurückgegeben hat. Unter 1 heißt meist, dass ein Teil der Daten im Auslagerungsspeicher liegt, und das ist schlimmer.
Trefferquote und Abgelaufene Schlüssel sind seit dem Start des Servers aufsummiert, nicht seit dem letzten Lesen: Eine Quote, die sich kaum bewegt, heißt nicht, dass es gerade keine Fehlzugriffe gibt. Bei den abgelaufenen Schlüsseln stehen die wegen Speichermangel verdrängten dabei.
Verbundene Clients wird an maxclients gemessen, das fehlt, wenn der Server CONFIG nicht erlaubt. Vergleichst du mit redis-cli, steht dort einer mehr: redis-cli selbst.
Operationen pro Sekunde berechnet der Server (instantaneous_ops_per_sec), nicht Calíope, und sie ändern sich von einem Moment zum nächsten.
Wenn Speicher oder Clients 90 % ihres Limits überschreiten, zeigt die Karte Nahe am Limit, mit einem Symbol zusätzlich zur Farbe.
Persistenz
Zeigt, ob AOF eingeschaltet ist, welche RDB-Sicherungen geplant sind (save), wann die letzte Sicherung war —mit Datum, Uhrzeit und Zeitzone— und wie viele Änderungen noch nicht gesichert sind; eine fehlgeschlagene Sicherung erscheint als solche, mit ihrem Symbol. Ist AOF aus und keine Sicherung geplant, sagt die Karte nur das, denn der Server verliert bei einem Neustart alle Daten. Lädt er gerade seinen Abzug von der Platte, sagt sie das zuerst: Bis das fertig ist, sind die Zahlen nicht die des laufenden Servers.
Pub/Sub
Eine Momentaufnahme bei jedem Lesen, kein Strom: Calíope abonniert keinen Kanal und zeigt keine Nachrichten. Aufgeführt werden die Kanäle, die gerade Abonnenten haben, mit ihrer Anzahl, und die Abonnements per Muster. Lässt der Server die Verbindung PUBSUB nicht nutzen, sagt die Karte das.
Server
Die Fußzeile nennt Version, Modus, Rolle, Protokoll (RESP2 oder RESP3) und Laufzeit. In einem Cluster gilt das Panel einem einzigen Knoten, und die Fußzeile nennt ihn.
Was die Speicheranalyse misst, was sie den Server kostet und warum ihre Summe nicht zu used_memory passt.
Wo es zu finden ist: Workspace › Werkzeuge › Speicher
Gilt für:Redis
Analysieren durchläuft die Schlüssel der Datenbank mit SCAN, misst jeden mit MEMORY USAGE und summiert das Gemessene nach Präfix; die Namen werden am selben Trennzeichen wie im Browser geteilt (:, wenn du kein anderes gewählt hast). Der Server kennt diese Gruppen nicht: Calíope bildet sie.
Was es kostet
Messen ist ein Lesezugriff pro Schlüssel, und in einer großen Datenbank ist das echte Last für einen Server, der Befehle einzeln abarbeitet. Deshalb läuft der Durchlauf seitenweise, hat eine Obergrenze und lässt sich anhalten. Die Obergrenze wählst du vor dem Analysieren im Limit-Menü neben Analysieren: von 10.000 bis 5.000.000 Schlüsseln, und 500.000, wenn du nichts änderst. Während er läuft, wird die Schaltfläche zu Stoppen, die auch im Aktivitätsbereich steht, und das Schließen des Tabs oder der Sitzung hält ihn an. Bis er fertig ist, bleibt die vorige Analyse sichtbar. In einem Cluster durchläuft er jeden Primärknoten und summiert.
Eine Schätzung, keine exakte Zählung
Ein String wird exakt gemessen. Eine Liste, ein Hash, eine Menge, eine sortierte Menge oder ein Stream werden per Stichprobe gemessen: Der Server sieht sich fünf Elemente an und schätzt den Rest (SAMPLES 5). Hat die Analyse an der Obergrenze angehalten oder hast du sie angehalten, warnt der Bildschirm, dass es eine Stichprobe ist, mit einem Symbol zusätzlich zum Text.
Die Tabelle Präfix, Speicher, Schlüssel und Anteil: Der Anteil bezieht sich auf das Gemessene, nicht auf die Datenbank. Das Sortiermenü daneben sortiert nach Speicher oder nach Schlüsseln, absteigend; auf dem Mac und auf einem breiten iPad lässt sich auch über die Spaltenüberschrift sortieren. Gruppen öffnen sich mit dem Chevron oder mit → und ← auf der Tastatur. Oben sagt die Zahl immer, wovon sie ist —wie viel die gemessenen Schlüssel belegen— und darunter, ob es alle Schlüssel der Datenbank sind (DBSIZE).
Warum die Summe nicht zu used_memory passt
Die Summe der Schlüssel ist immer kleiner als der Speicher, den der Server als belegt meldet (used_memory), und das ist kein Messfehler. used_memory zählt auch, was der Server für sich selbst belegt —ein leerer belegt schon fast 1 MB (used_memory_startup)—, die Puffer der Clients und der Replikation und die Schlüssel aller Datenbanken, während die Analyse nur die der Sitzung durchläuft. Am nächsten liegt used_memory_dataset, das den festen Teil abzieht, und selbst das enthält die anderen Datenbanken. Bei wenigen Schlüsseln ist der Abstand riesig; bei vielen nähert sich die Summe an.
Was das Protokoll langsamer Befehle von Redis festhält, warum sein Schwellenwert in Mikrosekunden angegeben ist und was beim Leeren passiert.
Wo es zu finden ist: Workspace › Werkzeuge › Langsame Befehle
Gilt für:Redis
Der Server hält jeden Befehl fest, dessen Ausführung länger dauert als ein Schwellenwert (SLOWLOG), und dieser Tab zeigt, was er festgehalten hat. Die Dauer ist die Arbeitszeit des Servers: Netzwerk und Wartezeit in der Warteschlange zählen nicht mit. Der Tab liest sich alle 5 Sekunden neu, solange er sichtbar ist, und Aktualisieren liest sofort neu.
Der Schwellenwert ist in Mikrosekunden
In Redis wird der Schwellenwert (slowlog-log-slower-than) in Mikrosekunden angegeben, nicht in Sekunden oder Millisekunden wie bei den anderen Engines: 10.000 µs sind 10 ms, der Wert, mit dem Redis ausgeliefert wird. Oben sagt die Karte Protokoll des Servers das in einem Satz, zusammen mit der Zahl der Einträge, die es behält (slowlog-max-len, 128, wenn niemand es geändert hat). Ein Schwellenwert von 0 hält alle Befehle fest, auch die schnellen; ein negativer schaltet das Protokoll ab, und dann sagt das die leere Liste: Das ist nicht dasselbe wie „kein Befehl hat den Schwellenwert überschritten“. In einem Cluster nennt die Karte den Knoten: Jeder Knoten führt sein eigenes Protokoll, und dies ist das des Knotens aus dem Profil.
Ein Fenster, kein Verlauf
Das Protokoll behält nur die letzten Einträge: Kommt ein neuer hinzu, wenn es voll ist, fällt der älteste heraus. Was du siehst, ist das, was der Server jetzt aufbewahrt, nicht alles, was seit seinem Start langsam war.
Einstellungen ändern Einstellungen ändern … öffnet ein Blatt mit Was protokolliert wird (Was den Schwellenwert überschreitet, Alles oder Nichts), Schwellenwert (µs) und Behaltene Einträge. Geschrieben wird mit CONFIG SET und danach neu gelesen, und angezeigt wird, was der Server nach eigener Aussage hat. Es wird nicht in seiner Konfigurationsdatei gespeichert: Ein Neustart stellt wieder her, was in dieser Datei steht.
Die Liste
Auf dem Mac ist sie ein Raster mit Beginn (Serveruhr), Dauer, Befehl und Client – Letztere nur, wenn der Server den Client mitschickt –, sortierbar per Klick auf die Kopfzeile. Auf iPhone und iPad ist sie eine Liste, und die Reihenfolge wählst du im Sortiermenü der Leiste: Neueste oder Langsamste. Das Feld Nach Befehl oder Client filtern filtert das bereits Gelesene, ohne erneut beim Server anzufragen. Der Server behält höchstens 32 Argumente pro Befehl, kürzt jedes auf 128 Bytes und sagt das im Befehl selbst (... (N more arguments)): Calíope zeigt es unverändert. Ein AUTH erscheint maskiert.
Die Details eines Eintrags
Wählst du einen Eintrag – auf dem Mac erscheinen sie unter dem Raster, auf iPhone und iPad nach dem Antippen in einem Blatt –, siehst du den ganzen Befehl, die Uhrzeit mit Zeitzone (die Uhr ist die des Servers), die Dauer in ms und µs, Adresse und Name des Clients sowie die Nummer des Eintrags. Befehl kopieren kopiert ihn; In der Konsole öffnen lässt ihn eingetippt in der Konsole stehen, ohne ihn auszuführen. Beides steht auch im Kontextmenü, und auf dem Mac öffnen Doppelklick oder Return die Konsole.
Leeren Protokoll leeren in der Leiste löscht alle Einträge auf dem Server (SLOWLOG RESET). Vorher fragt es nach und sagt, wie viele verschwinden, gezählt in diesem Moment mit SLOWLOG LEN. Das lässt sich nicht rückgängig machen.
Wer mit dem Redis-Server verbunden ist, was verbunden, inaktiv und die Flags bedeuten und was beim Trennen eines Clients passiert.
Wo es zu finden ist: Workspace › Werkzeuge › Clients
Gilt für:Redis
Dieser Tab zeigt, was CLIENT LIST antwortet: jede offene Verbindung zum Server, ob von einer Anwendung, von redis-cli oder von Calíope selbst. Die Liste liest sich alle 5 Sekunden neu, solange sie sichtbar ist, und Aktualisieren liest sie sofort neu. Das Feld Nach Name, Adresse oder Befehl filtern filtert das bereits Gelesene —Name, Adresse, letzter Befehl, Benutzer, Bibliothek und ID—, ohne zum Server zurückzugehen. In einem Cluster ist die Liste die des Knotens aus dem Profil, und ein Hinweis sagt es: Jeder Knoten hat seine eigenen Clients.
Die Spalten
Auf dem Mac ist es ein Raster mit Client, ID, Adresse, Verbunden, Inaktiv, Datenbank, Letzter Befehl, Flags und Speicher, das sich durch Klicken auf die Kopfzeile sortieren lässt; Benutzer und Bibliothek erscheinen nur, wenn eine Verbindung sie mitbringt (den ACL-Benutzer gibt es seit Redis 6; die Bibliothek seit Redis 7.2 und nur, wenn sich der Client vorgestellt hat). Auf iPhone und iPad ist jeder Client eine Zeile mit denselben Daten, beschriftet, und die Reihenfolge wählt man im Sortiermenü der Leiste: Nach ID, Am längsten inaktiv, Zuletzt verbunden oder Meister Speicher.
Verbunden und inaktiv sind nicht dasselbe Verbunden (age) zählt die Sekunden seit dem Öffnen der Verbindung; Inaktiv (idle) die Sekunden seit ihrem letzten Befehl. Eine Pool-Verbindung ist seit Stunden verbunden und seit wenigen Sekunden inaktiv; eine, die lange inaktiv ist, steht offen, ohne etwas zu tun, und belegt trotzdem Speicher auf dem Server. Ein Client, der blockiert auf Daten wartet —etwa ein BLPOP—, sammelt beim Warten ebenfalls Inaktivität an, und sein letzter Befehl zeigt es. Speicher (tot-mem) ist, was die Verbindung auf dem Server belegt, Ein- und Ausgabepuffer eingeschlossen.
Die Flags Flags (flags) erscheint so, wie der Server es schreibt, ein Buchstabe pro Flag. Die häufigsten: N, keines im Besonderen (eine normale Verbindung); b, blockiert, wartet auf Daten (BLPOP, XREAD BLOCK…); P, für Pub/Sub abonniert; x, innerhalb eines noch nicht ausgeführten MULTI; S, ein mit diesem Server verbundenes Replikat; M, der Primärserver, auf der Verbindung, die ein Replikat zu ihm hält; und O, ein Client im MONITOR.
Die Verbindungen von Calíope stehen in der Liste
Auch Calíope ist ein Client, also erscheinen seine Verbindungen in der Liste, mit dem Namen Caliope und der Bibliothek caliope; ihr letzter Befehl ist meist das Lesen selbst (client|list). Sie sind mit einem Symbol und der Beschriftung Diese Sitzung markiert und lassen sich von hier aus nicht trennen: Sie zu schließen würde die Sitzung schließen. Calíope erkennt sie an ihrer ID, nicht am Namen: Eine andere Calíope-Instanz, die mit demselben Server verbunden ist, heißt genauso, und die ist tatsächlich ein anderer Client.
Trennen Trennen … schließt die Verbindung des ausgewählten Clients (CLIENT KILL ID). Vorher fragt es immer nach, nennt den Client, seine Adresse, seine ID und seinen letzten Befehl und warnt, dass verloren geht, was er gerade halb erledigt hatte —eine Transaktion, ein Abonnement oder ein blockierter Befehl—; bestätigt wird mit Trennen. Auf dem Mac gelangt man über die Leiste und das Kontextmenü dorthin; auf iPhone und iPad über das Kontextmenü und durch Wischen der Zeile nach links, was nachfragt und nicht trennt. Danach verschwindet die Zeile an Ort und Stelle, und ein Hinweis sagt es. Der Client kann sich wieder verbinden —viele Pools tun das von selbst—, und dann erscheint er beim nächsten Lesen mit einer anderen ID. Das Kontextmenü hat außerdem Adresse kopieren.
Wenn der Server 0 antwortet
War der Client zwischen dem Lesen und der Bestätigung schon gegangen, antwortet der Server, dass er 0 Verbindungen geschlossen hat. Das ist kein Fehler: Calíope sagt, dass er nicht mehr verbunden war, und entfernt die Zeile.
Wie man in der Redis-Konsole einen Befehl eingibt und die Antwort liest, welche Befehle sie nicht ausführt und warum, und bei welchen man zuerst ihren Namen eintippen muss.
Wo es zu finden ist: Workspace › Werkzeuge › Konsole
Gilt für:Redis
Die Konsole schickt Redis den Befehl, den du eingibst, über dieselbe Sitzung wie die anderen Tabs. Ausführen —oder Return— führt ihn aus; auf dem Mac bricht Wahltaste+Return die Zeile um, ohne sie auszuführen —ein langer Befehl passt so auf mehrere Zeilen, und der Umbruch zählt als Leerzeichen—, und auf iPhone und iPad führt die Eingabetaste immer aus. Die Zeile wird zerlegt wie in redis-cli: Argumente sind durch Leerzeichen getrennt, und einfache oder doppelte Anführungszeichen fassen Text mit Leerzeichen zu einem Argument zusammen; innerhalb doppelter Anführungszeichen gelten \n, \t und \xHH. Ein nicht geschlossenes Anführungszeichen wird nicht gesendet, und die Ausgabe sagt, warum.
Der Verlauf
Der Pfeil nach oben holt den vorigen Befehl zurück, wenn der Cursor in der ersten Zeile steht, und der Pfeil nach unten den nächsten, wenn er in der letzten steht; die Tasten Vorheriger Befehl im Verlauf und Nächster Befehl im Verlauf tun dasselbe ohne Tastatur. Er behält die letzten 200 Zeilen, auch die, die die Konsole nicht ausgeführt hat, ohne dieselbe zweimal hintereinander. Leeren leert die Ausgabe, nicht den Verlauf. Ausgabe, Verlauf und das gerade Eingetippte sind noch da, wenn du den Tab wechselst und zurückkommst.
Eine Antwort lesen
- Ein Status wie OK oder PONG erscheint unverändert.
- Vor einer Ganzzahl steht (Ganzzahl).
- Text steht immer in Anführungszeichen, Steuerzeichen werden wie in redis-cli maskiert ("a\r\nb"); Text, der kein UTF-8 ist, erscheint hexadezimal mit seiner Länge in Bytes.
- (null) bedeutet, dass es keinen Wert gibt, und ist nicht dasselbe wie die leere Zeichenkette, die als "" erscheint.
- Eine Liste ist nummeriert, und eine leere zeigt (leeres Array). Eine Map —was HGETALL oder CONFIG GET zurückgeben— erscheint als nummerierte Paare Feld => Wert. Eine Menge hat eine Kopfzeile, die sagt, wie viele Elemente sie hat und dass sie keine Reihenfolge haben, und ihre Elemente stehen mit Aufzählungszeichen, ohne Nummer.
- Ein Fehler erscheint rot, mit einem Symbol und (Fehler) davor, und mit dem Präfix, das der Server ihm gibt (WRONGTYPE, ERR…).
- Eine Antwort mit mehr als 2000 Zeilen wird abgeschnitten, und der Hinweis verweist auf „Schlüssel“, das die Schlüssel seitenweise durchläuft.
In einem Cluster steht unter jeder Antwort, wer geantwortet hat: der Primärknoten des Slots des ersten Schlüssels oder, wenn der Befehl keinen Schlüssel hat, der Knoten des Profils. Ein Befehl ohne Schlüssel —DBSIZE, INFO— zählt nur diesen Knoten.
Was die Konsole nicht ausführt, und warum
Jede Ablehnung erscheint in der Ausgabe mit ihrem Grund, und der Befehl erreicht den Server nicht. Darunter öffnet „Was man nicht tun sollte“ das Thema des DBA-Handbuchs, das erklärt, warum:
- KEYS durchläuft alle Schlüssel auf einmal und blockiert den Server, solange es läuft. Zum Suchen von Schlüsseln gibt es „Schlüssel“, das sie seitenweise mit SCAN durchläuft.
- MONITOR bremst den Server, solange es läuft, und lässt sich von außen nicht beenden.
- SUBSCRIBE, PSUBSCRIBE und SSUBSCRIBE würden die Nachrichten des Kanals vermischt mit den Antworten anderer Befehle liefern. Die aktiven Kanäle und ihre Abonnenten stehen unter „Server“.
- SHUTDOWN fährt den Server herunter.
- DEBUG hat Unterbefehle, die den Server anhalten oder abstürzen lassen (DEBUG SLEEP, DEBUG SEGFAULT).
- RESET und HELLO ändern das Protokoll unter der Verbindung, die Calíope gerade nutzt, und CLIENT REPLY OFF oder SKIP antworten nicht mehr: Der nächste Befehl würde für immer auf seine Antwort warten. SYNC und PSYNC machen aus der Verbindung eine Replikat-Verbindung, die alles empfängt, was auf den Server geschrieben wird.
- SELECT ließe die Oberfläche eine Datenbank zeigen und eine andere lesen: Die Datenbank wählt man mit der Auswahl des Werkzeugs.
- MULTI, EXEC, DISCARD, WATCH und UNWATCH: Eine Transaktion lebt auf einer einzigen Verbindung, und die Konsole schickt jede Zeile über die gerade freie, sodass die nächsten Befehle auf einer anderen landen könnten und die Transaktion offen bliebe. Für mehrere Befehle, die zusammen und ohne etwas dazwischen laufen, gibt es EVAL mit einem Skript.
- Ein Befehl, der auf Daten wartet —BLPOP, BRPOP, BLMOVE, BZPOPMIN, XREAD … BLOCK, WAIT…—, mit einer Wartezeit von 0, also ohne Ende, oder von mehr als 10 Sekunden (mehr als 10000 Millisekunden bei XREAD BLOCK, WAIT und WAITAOF): Solange er wartet, hält er eine der Verbindungen fest, die alle Werkzeuge der Sitzung nutzen. Mit einer kürzeren Wartezeit wird er ausgeführt.
Befehle, bei denen man ihren Namen eintippt FLUSHDB und FLUSHALL löschen alle Schlüssel —der Datenbank oder aller Datenbanken— und lassen sich nicht rückgängig machen; REPLICAOF, SLAVEOF, CLUSTER RESET und CLUSTER FAILOVER ändern die Topologie, und andere Clients können den Zugriff auf ihre Daten verlieren. Für diese erscheint über dem Feld ein Streifen, der sagt, was gelöscht oder geändert wird und auf welchem Server, mit einem Feld, in das man den Namen des Befehls tippt —Groß- und Kleinschreibung egal—, und einer Taste, die erst danach aktiv wird. Abbrechen lässt den Befehl ungesendet, und die Ausgabe sagt es.
Alles andere wird ausgeführt, auch EVAL, CONFIG SET und CLIENT KILL. Was ausgeführt wird, landet im Befehlsprotokoll, mit dem AUTH-Passwort verdeckt.
Diese Liste steht im Code von Calíope, an einer einzigen Stelle, und jeder Weg, der einen von dir eingetippten Befehl ausführt, fragt sie ab: Ändert sie sich, ändert sich dieses Thema mit ihr.
Was die Topologie einer Redis-Sitzung zeigt: Primäre, Replikate und Shards, warum die Verzögerung in Bytes gemessen wird, was Slots sind, was es heißt, wenn der Cluster ausfällt, und warum Sentinel fehlt.
Wo es zu finden ist: Workspace › Werkzeuge › Topologie
Gilt für:Redis
Die Topologie zeigt, wie der Server der Sitzung aufgebaut ist. Ein Cluster erscheint als Cluster, ein einzelner Knoten mit Replikaten als Einzelner Knoten und seine Replikation. Oben steht eine Zusammenfassung: wie viele Knoten und wie viele Primäre antworten, und die, die nicht antworten, mit ihrer Adresse. Darunter zeichnet Diagramm einen Kasten pro Knoten, nach Shard gruppiert, mit dem Primären oben und seinen Replikaten darunter, und Knoten zeigt dasselbe als Tabelle. Sie liest sich alle 5 Sekunden neu, solange sie sichtbar ist, und Aktualisieren liest sie sofort neu.
Die Verzögerung ist in Bytes, nicht in Sekunden
Ein Redis-Replikat bestätigt keine Uhrzeit, sondern bis zu welchem Byte des Replikationsstroms es empfangen hat. Deshalb ist die Spalte Rückstand (Bytes) die Position des Primären minus die des Replikats. Calíope liest den Primären zweimal, bevor es irgendwen fragt und am Ende: Was er zwischen den beiden Lesungen vorgerückt ist, ist der Boden, und darunter erscheint das Replikat als Aktuell, weil sich diese Differenz nicht von der Zeit unterscheiden lässt, die eine Anfrage an eine andere Maschine braucht. Erst darüber erscheint Im Rückstand. Das lag=, das Redis in INFO replication neben jedes Replikat schreibt, ist etwas anderes: die Sekunden seit seiner letzten Bestätigung.
Wenn ein Primärer neu startet, beginnt er einen neuen Strom, und sein Replikat hat keine messbare Verzögerung, bis es sich neu synchronisiert hat: Die Tabelle zeigt In einem anderen Replikationsstrom als sein Primärknoten und als Verzögerung „nicht gemessen (anderer Strom)“, statt 0 Bytes anzuzeigen. Hat das Replikat die Verbindung zu seinem Primären verloren, erscheint Verbindung zum Primärknoten unterbrochen.
Slots
Ein Cluster verteilt die Schlüssel auf 16384 Slots: Jeder Schlüssel landet nach dem CRC16 seines Namens in einem davon, und jeder Primäre bedient einen Bereich. Die Zahl ist fest und mit Absicht klein: Die Karte, welcher Primäre welchen Slot bedient, wandert mit jedem Heartbeat zwischen den Knoten und muss klein bleiben. Die Spalte Slots nennt den Bereich jedes Primären, und die Zusammenfassung sagt, wie viele der 16384 einen Besitzer haben.
Wenn der Cluster ausfällt
„Cluster-Status: fail“ heißt, dass der Cluster keine Befehle mehr annimmt: Für manche Slots gibt es keinen lebenden Primären mehr, weil ein Primärer ohne Replikat zum Einspringen ausgefallen ist oder mehrere gleichzeitig. Ein Knoten, der nicht antwortet, erscheint als Antwortet nicht, mit dem technischen Fehler daneben, und über ihn wird nichts weiter behauptet: weder seine Rolle noch seine Verzögerung.
Sentinel fehlt
Eine Sitzung gegen Sentinel zeigt keine Topologie: Sentinel überwacht die Primären und entscheidet das Failover, speichert aber keine Daten und hat keine eigenen Replikate. Um einen Primären mit seinen Replikaten zu sehen, öffne die Sitzung gegen den Primären.
Mit VoiceOver ist die Tabelle die Alternative zum Diagramm: Jede Zeile wird einmal vorgelesen, mit dem Namen jeder Spalte vor ihrem Wert.
Was ein Redis-Bericht ist, welche Felder er hat und was er den Server kostet: einen Schlüsseldurchlauf bei jeder Ausführung.
Wo es zu finden ist: Workspace › Werkzeuge › Berichte
Gilt für:Redis
Ein Redis-Bericht hat keine Abfrage: Er ist ein Schlüsseldurchlauf, der zur Tabelle wird, mit einer Zeile pro Schlüssel. Du legst ihn mit Neuer Bericht in einer Redis-Sitzung an, und statt des Texteditors erscheinen seine Felder.
Was du wählst Muster ist ein Glob auf den Schlüsselnamen (app:*, sitzung:??, user:[ab]*); leer heißt alle. Typ behält nur Schlüssel dieses Typs. Spalten schaltet key, type, ttl, memory, encoding und length ein, und sie erscheinen in der Reihenfolge, in der du sie einschaltest; in Hash-Felder ist jedes Feld, durch Kommas getrennt, eine weitere Spalte mit dem Wert dieses Hash-Felds, leer bei einem Schlüssel, der kein Hash ist oder das Feld nicht hat. Zeilenobergrenze legt fest, wie viele Zeilen höchstens; leer ist die Obergrenze der Engine.
Was es kostet
Jedes Mal, wenn du Ausführen drückst, durchläuft Calíope mit SCANalle Schlüssel, die zum Muster passen – im Cluster auf jedem Primary – und fragt erst danach die Spalten der Zeilen ab, die bleiben. Die Obergrenze kürzt die Zeilen, nicht den Durchlauf: Mit einem weiten Muster auf einer Datenbank mit Millionen Schlüsseln dauert der Bericht, auch wenn er nur zehn will. Stoppen hält ihn vor der nächsten Seite des Durchlaufs an.
Die Tabelle
Die Zeilen kommen nach Schlüssel sortiert, sodass zwei Ausführungen dieselbe Tabelle liefern; gibt es mehr als die Obergrenze, bleiben die ersten in dieser Reihenfolge, und die Tabelle sagt, dass gekürzt wurde. memory ist, was MEMORY USAGE antwortet: Bei einer Collection ist es eine Schätzung per Stichprobe. Ein Schlüssel oder Feld, das kein UTF-8 ist, erscheint als 0x… mit seiner Länge, und seine Spalte wird als binär markiert.
Parameter
Ein Parameter wird als $$name ins Muster geschrieben und mit Parameter deklarieren deklariert. Sein Wert wird wörtlich gesucht: Ein * im Wert ist ein Sternchen, kein Platzhalter. Er wird nach seinem deklarierten Typ geschrieben, und ein Wert, der nicht von diesem Typ ist, wird vor der Ausführung abgelehnt.
Der Rest Exportieren speichert ihn in jedem Format des Menüs, PDF eingeschlossen, und Verlauf bewahrt jede Ausführung auf, mit ihren Zeilen oder mit ihrem Fehler. Ein Redis-Bericht läuft nur in einer Redis-Sitzung: In jeder anderen sagt das Werkzeug, dass der Bericht nicht zu dieser Sitzung gehört, und lässt ihn nicht ausführen. Planen hilft bei ihm nicht: Planen lassen sich nur Berichte auf einer relationalen Datenbank, und in jeder Runde wird der Redis-Bericht im Verlauf als Übersprungen vermerkt.