Cette page décrit Calíope 1.6, la version que je construis en ce moment. La 1.5 est sur l'App Store pour Mac, iPad, iPhone, Apple Watch, Apple TV et Apple Vision Pro. Le changelog indique dans quelle version chaque fonction est arrivée.
Ajoute un bouton « Ouvrir dans Calíope » à chaque sujet. Ne fonctionne qu'avec l'app installée.
Comment parcourir, lire et modifier les clés d’un serveur Redis.
Où le trouver : Espace de travail › Outils › Clés
S'applique à :Redis
L’explorateur affiche à gauche les clés de la base, regroupées par préfixe, et à droite le détail de celle que vous choisissez.
Comment les clés sont parcourues
Calíope les demande avec SCAN, par lots, et jamais avec KEYS : KEYS parcourt toute la base d’un coup et, comme Redis traite les commandes une par une, il ne répond à personne d’autre tant que cela dure. Le pied indique combien de clés ont été parcourues et si le parcours est terminé ou s’il reste des clés ; Charger plus de clés demande le lot suivant. Dans un cluster, chaque nœud primaire est parcouru et le pied indique combien ont répondu ; s’il en manque un, il le nomme avec son motif.
Le champ du haut est un motif MATCH —app:*, *:1001—, pas une recherche par contenu, et le serveur l’applique dès que vous cessez de taper.
Les groupes sont faits par Calíope, pas par le serveur
Redis n’a pas de dossiers : chaque clé est un nom plat. Les groupes viennent du découpage des noms par le caractère du menu Séparateur de la barre (:, /, ., | ou Aucun : liste plate), et le serveur n’en sait rien. Le séparateur se choisit pour chaque session, et chaque groupe indique combien de clés en dépendent. Au clavier, les flèches parcourent la liste et → et ← ouvrent et ferment le groupe choisi ; sur l’iPhone, toucher une clé ouvre son détail.
Type et expiration
Chaque clé porte son type, avec son glyphe et son nom, et son expiration, qui décompte dans le détail. Sans expiration et N’existe plus ne sont pas la même chose : la première est une clé qui dure jusqu’à ce que quelqu’un la supprime ; la seconde, une clé qui a expiré, ou qu’un autre client a supprimée, après avoir été parcourue.
Le détail
Sous la clé, le type et l’expiration viennent la taille —Longueur en octets, Champs ou Éléments—, l’Encodage interne et la Mémoire, puis la Valeur. La taille est demandée avant le contenu : une grande valeur se lit par morceaux, et un bouton charge le suivant. Dans une liste, chaque élément porte son Indice, car dans Redis la position fait partie de la donnée ; un ensemble prévient qu’il n’a pas d’ordre ; un ensemble trié affiche chaque Membre à côté de son Score, du plus petit au plus grand ; et un stream affiche d’abord ses propres données —première et dernière entrée, dernier id généré, plus grand id supprimé—, puis ses groupes de consommateurs avec leurs entrées en attente et leur retard, et enfin ses Entrées. Une valeur qui n’est pas en UTF-8 s’affiche en hexadécimal, et les caractères de contrôle, échappés.
Ce qui peut être modifié
Sur la clé choisie, depuis la barre et depuis le menu contextuel de la liste : Expiration… (ou Retirer l’expiration, si la clé expire) ; Renommer…, qui prévient si le nom existe déjà et n’écrase l’autre clé qu’avec Remplacer ; et Supprimer la clé…, qui demande toujours confirmation et nomme la clé, son type et sa taille. La touche Supprimer mène à cette même question, et sur l’iPhone et l’iPad, le balayage de la ligne vers la gauche.
Dans la valeur : Modifier la valeur… sur une chaîne, qui conserve son expiration ; Ajouter un champ…, Modifier… et Retirer sur un hash ; Modifier… d’une position dans une liste ; Ajouter un membre… et Retirer sur un ensemble ; et Ajouter un membre…, Modifier… —qui change le score— et Retirer sur un ensemble trié. Retirer le dernier élément prévient que Redis supprime la clé dès qu’elle est vide. Chaque changement apparaît en place, sans recharger la liste, et reste dans le journal de ce que Calíope a exécuté.
Une valeur binaire ne se modifie pas, ni une valeur de plus de 64 Kio, ni un stream. Et il n’y a ni vidage de la base ni suppression par motif : on supprime une clé à la fois, en sachant laquelle.
Profils ouverts avec Calíope 1.4
Un profil Redis synchronisé avec un appareil qui a encore Calíope 1.4 y est lu comme MariaDB sur le même port, car cette version ne connaît pas Redis ; si vous l’enregistrez depuis cet appareil, il est réécrit ainsi sur tous les vôtres. On le récupère en choisissant de nouveau Redis dans le profil : ni le serveur ni le mot de passe ne sont perdus.
Ce que montre le panneau du serveur Redis et comment lire chaque chiffre.
Où le trouver : Espace de travail › Outils › Serveur
S'applique à :Redis
Le panneau montre l’état du serveur Redis tel que INFO le publie. Il se relit tout seul toutes les 2 secondes tant qu’il est à l’écran, et Actualiser le relit aussitôt. Sous chaque chiffre figure le champ d’INFO d’où il vient, pour que vous puissiez le comparer avec redis-cli.
Les six cartes Mémoire utilisée est used_memory, avec la limite (maxmemory) et le pourcentage, ou sans limite si maxmemory vaut 0 ; en dessous, ce que fait le serveur quand il est plein, et le pic.
Fragmentation est la mémoire que le processus occupe dans le système divisée par celle qu’il utilise. Au-dessus de 1, le processus occupe plus qu’il n’utilise : des trous que l’allocateur de mémoire n’a pas encore rendus. En dessous de 1, cela signifie souvent qu’une partie des données est dans le fichier d’échange, et c’est pire.
Taux de succès et Clés expirées sont cumulés depuis le démarrage du serveur, pas depuis la dernière lecture : un taux qui bouge à peine ne dit pas qu’il n’y a pas d’échecs en ce moment. Les clés expirées sont accompagnées des clés évincées faute de mémoire.
Clients connectés se mesure par rapport à maxclients, qui n’apparaît pas si le serveur n’autorise pas CONFIG. Si vous comparez avec redis-cli, vous en verrez un de plus là-bas : redis-cli lui-même.
Opérations par seconde sont calculées par le serveur (instantaneous_ops_per_sec), pas par Calíope, et changent d’un instant à l’autre.
Quand la mémoire ou les clients dépassent 90 % de leur limite, la carte indique Proche de la limite, avec un glyphe en plus de la couleur.
Persistance
Indique si AOF est activé, quelles sauvegardes RDB sont programmées (save), quand a eu lieu la dernière sauvegarde —avec date, heure et fuseau— et combien de modifications ne sont pas encore sauvegardées ; une sauvegarde échouée apparaît comme telle, avec son glyphe. Si AOF est désactivé et qu’aucune sauvegarde n’est programmée, la carte ne dit que cela, car le serveur perd toutes ses données s’il redémarre. S’il charge son instantané depuis le disque, il le dit d’abord : tant que ce n’est pas fini, les chiffres ne sont pas ceux du serveur en marche.
Pub/sub
Une photo prise à chaque lecture, pas un flux : Calíope ne s’abonne à aucun canal et n’affiche aucun message. Il liste les canaux qui ont des abonnés en ce moment, avec leur nombre, et les abonnements par motif. Si le serveur ne laisse pas la connexion utiliser PUBSUB, la carte le dit.
Serveur
Le pied donne la version, le mode, le rôle, le protocole (RESP2 ou RESP3) et la durée de fonctionnement. Dans un cluster, le panneau concerne un seul nœud, et le pied le nomme.
Ce que mesure l’analyseur de mémoire, ce qu’il coûte au serveur et pourquoi sa somme ne correspond pas à used_memory.
Où le trouver : Espace de travail › Outils › Mémoire
S'applique à :Redis
Analyser parcourt les clés de la base avec SCAN, mesure chacune avec MEMORY USAGE et additionne ce qu’il a mesuré par préfixe, en coupant les noms sur le même séparateur que l’explorateur (: si vous n’en avez pas choisi un autre). Le serveur ne connaît pas ces groupes : c’est Calíope qui les construit.
Ce que cela coûte
Mesurer, c’est une lecture par clé, et dans une grande base c’est une vraie charge pour un serveur qui traite les commandes une à une. C’est pourquoi le parcours avance page par page, a un plafond et peut être arrêté. Le plafond se choisit avant d’analyser, dans le menu du plafond à côté de Analyser : de 10 000 à 5 000 000 clés, et 500 000 si vous ne le changez pas. Pendant qu’il tourne, le bouton devient Arrêter, qui figure aussi dans le panneau Activité, et fermer l’onglet ou la session l’arrête. Jusqu’à la fin, l’analyse précédente reste affichée. Dans un cluster, il parcourt chaque primaire et additionne.
Une estimation, pas un compte exact
Une chaîne est mesurée exactement. Une liste, un hash, un ensemble, un ensemble trié ou un stream sont mesurés par échantillonnage : le serveur regarde cinq éléments et estime le reste (SAMPLES 5). Si l’analyse s’est arrêtée au plafond ou si vous l’avez arrêtée, l’écran prévient que c’est un échantillon, avec un glyphe en plus du texte.
La grille Préfixe, Mémoire, Clés et Part : la part est celle de ce qui a été mesuré, pas de la base. Le menu de tri, juste à côté, trie par mémoire ou par clés, du plus grand au plus petit ; sur le Mac et sur un iPad large, on trie aussi en touchant l’en-tête de la colonne. Les groupes s’ouvrent avec le chevron, ou avec → et ← au clavier. En haut, le chiffre dit toujours de quoi il s’agit —ce qu’occupent les clés mesurées— et, en dessous, si ce sont toutes les clés de la base (DBSIZE).
Pourquoi la somme ne correspond pas à used_memory
La somme des clés est toujours inférieure à la mémoire que le serveur dit utiliser (used_memory), et ce n’est pas une erreur de mesure. used_memory compte aussi ce que le serveur occupe pour lui-même —un serveur vide utilise déjà près de 1 Mo (used_memory_startup)—, les tampons des clients et de la réplication, et les clés de toutes les bases, alors que l’analyse ne parcourt que celle de la session. Le chiffre le plus proche est used_memory_dataset, qui retire la part fixe, et même lui inclut les autres bases. Avec peu de clés l’écart est énorme ; avec beaucoup, la somme s’en approche.
Ce que note le journal des commandes lentes de Redis, pourquoi son seuil est en microsecondes et ce qui se passe quand on le vide.
Où le trouver : Espace de travail › Outils › Commandes lentes
S'applique à :Redis
Le serveur note chaque commande dont l’exécution dépasse un seuil (SLOWLOG), et cet onglet affiche ce qu’il a noté. La durée est celle du travail du serveur : elle ne compte ni le réseau ni l’attente dans la file. L’onglet se relit tout seul toutes les 5 secondes tant qu’il est visible, et Actualiser le relit aussitôt.
Le seuil est en microsecondes
Dans Redis, le seuil (slowlog-log-slower-than) s’écrit en microsecondes, et non en secondes ou en millisecondes comme dans les autres moteurs : 10 000 µs font 10 ms, la valeur d’origine de Redis. En haut, la carte Journal du serveur le dit en une phrase, avec le nombre d’entrées qu’il garde (slowlog-max-len, 128 si personne ne l’a changé). Un seuil de 0 note toutes les commandes, même les rapides ; un seuil négatif éteint le journal, et la liste vide le dit alors : ce n’est pas la même chose que « aucune commande n’a dépassé le seuil ». Dans un cluster, la carte nomme le nœud : chaque nœud tient son propre journal, et celui-ci est celui du nœud du profil.
Une fenêtre, pas un historique
Le journal ne garde que les dernières entrées : quand une nouvelle arrive et qu’il est plein, la plus ancienne sort. Ce que vous voyez, c’est ce que le serveur conserve maintenant, pas tout ce qui a été lent depuis son démarrage.
Changer les réglages Modifier les réglages… ouvre une feuille avec Ce qui est noté (Ce qui dépasse le seuil, Tout ou Rien), Seuil (µs) et Entrées gardées. C’est écrit avec CONFIG SET puis relu, et ce qui s’affiche ensuite est ce que le serveur dit avoir. Ce n’est pas enregistré dans son fichier de configuration : un redémarrage remet ce que dit ce fichier.
La liste
Sur le Mac, c’est une grille avec Début (horloge du serveur), Durée, Commande et Client — cette dernière seulement si le serveur envoie le client —, triée en cliquant sur l’en-tête. Sur l’iPhone et l’iPad, c’est une liste, et l’ordre se choisit dans le menu de tri de la barre : Plus récentes ou Plus lentes. Le champ Filtrer par commande ou client filtre ce qui a déjà été lu, sans revenir au serveur. Le serveur garde au plus 32 arguments de chaque commande et coupe chacun à 128 octets, et il le dit dans la commande elle-même (... (N more arguments)) : Calíope l’affiche tel quel. Un AUTH apparaît masqué.
Le détail d’une entrée
En choisissant une entrée — sur le Mac, il apparaît sous la grille ; sur l’iPhone et l’iPad, en la touchant, dans une feuille —, on voit la commande entière, l’heure avec son fuseau (l’horloge est celle du serveur), la durée en ms et en µs, l’adresse et le nom du client, et le numéro de l’entrée. Copier la commande la copie ; Ouvrir dans la console la laisse écrite dans la console, sans l’exécuter. Les deux sont aussi dans le menu contextuel, et sur le Mac un double-clic ou Retour ouvrent la console.
Vider Vider le journal, dans la barre, efface toutes les entrées du serveur (SLOWLOG RESET). Il demande d’abord, en disant combien partent, comptées à ce moment-là avec SLOWLOG LEN. C’est irréversible.
Qui est connecté au serveur Redis, ce que signifient connecté, inactif et les indicateurs, et ce qui se passe quand on déconnecte un client.
Où le trouver : Espace de travail › Outils › Clients
S'applique à :Redis
Cet onglet affiche ce que répond CLIENT LIST : chaque connexion ouverte sur le serveur, qu’elle vienne d’une application, de redis-cli ou de Calíope lui-même. La liste se relit toute seule toutes les 5 secondes tant qu’elle est visible, et Actualiser la relit aussitôt. Le champ Filtrer par nom, adresse ou commande filtre ce qui a déjà été lu —nom, adresse, dernière commande, utilisateur, bibliothèque et ID— sans revenir au serveur. Dans un cluster, la liste est celle du nœud du profil, et un avis le dit : chaque nœud a ses propres clients.
Les colonnes
Sur le Mac, c’est une grille avec Client, ID, Adresse, Connecté, Inactif, Base, Dernière commande, Indicateurs et Mémoire, que l’on trie en cliquant sur l’en-tête ; Utilisateur et Bibliothèque n’apparaissent que si une connexion les fournit (l’utilisateur ACL existe depuis Redis 6 ; la bibliothèque, depuis Redis 7.2 et seulement si le client s’est présenté). Sur l’iPhone et l’iPad, chaque client est une ligne avec ces mêmes données, étiquetées, et l’ordre se choisit dans le menu de tri de la barre : Par ID, Les plus inactifs, Connectés le plus récemment ou Le plus de mémoire.
Connecté et inactif, ce n’est pas pareil Connecté (age) compte les secondes depuis l’ouverture de la connexion ; Inactif (idle), les secondes depuis sa dernière commande. Une connexion de pool est connectée depuis des heures et inactive depuis quelques secondes ; une connexion inactive depuis longtemps est ouverte sans rien faire, et occupe pourtant de la mémoire sur le serveur. Un client bloqué en attente de données —un BLPOP, par exemple— accumule aussi de l’inactivité pendant qu’il attend, et sa dernière commande le dit. Mémoire (tot-mem) est ce que la connexion occupe sur le serveur, tampons d’entrée et de sortie compris.
Les indicateurs Indicateurs (flags) s’affiche tel que l’écrit le serveur, une lettre par indicateur. Les plus courants : N, aucun en particulier (une connexion normale) ; b, bloquée en attente de données (BLPOP, XREAD BLOCK…) ; P, abonnée à pub/sub ; x, dans un MULTI pas encore exécuté ; S, une réplique connectée à ce serveur ; M, le primaire, sur la connexion qu’une réplique garde avec lui ; et O, un client en MONITOR.
Les connexions de Calíope sont dans la liste
Calíope est aussi un client, donc ses connexions apparaissent dans la liste, avec le nom Caliope et la bibliothèque caliope ; leur dernière commande est en général la lecture elle-même (client|list). Elles sont marquées d’un symbole et de l’étiquette Cette session, et on ne peut pas les déconnecter d’ici : les fermer fermerait la session. Calíope les reconnaît à leur ID, pas à leur nom : une autre instance de Calíope connectée au même serveur porte le même nom, et celle-là est bien un autre client.
Déconnecter Déconnecter… ferme la connexion du client sélectionné (CLIENT KILL ID). Il demande toujours d’abord, en nommant le client, son adresse, son ID et sa dernière commande, et en prévenant que ce qu’il avait en cours —une transaction, un abonnement ou une commande bloquée— est perdu ; on confirme avec Déconnecter. Sur le Mac, on y arrive par la barre et par le menu contextuel ; sur l’iPhone et l’iPad, par le menu contextuel et en balayant la ligne vers la gauche, ce qui demande sans déconnecter. Ensuite, la ligne disparaît sur place et un avis le dit. Le client peut se reconnecter —beaucoup de pools le font tout seuls—, et il réapparaît alors à la lecture suivante avec un autre ID. Le menu contextuel propose aussi Copier l’adresse.
Quand le serveur répond 0
Si le client était déjà parti entre la lecture et la confirmation, le serveur répond qu’il a fermé 0 connexion. Ce n’est pas un échec : Calíope dit qu’il n’était plus connecté et retire la ligne.
Comment saisir et lire une commande dans la console Redis, quelles commandes elle n’exécute pas et pourquoi, et lesquelles demandent de taper leur nom d’abord.
Où le trouver : Espace de travail › Outils › Console
S'applique à :Redis
La console envoie à Redis la commande que vous tapez, par la même session que les autres onglets. Exécuter —ou Entrée— l’exécute ; sur le Mac, Option+Entrée coupe la ligne sans l’exécuter —une longue commande tient sur plusieurs, et le saut compte comme une espace—, et sur l’iPhone et l’iPad la touche Retour exécute toujours. La ligne est découpée comme dans redis-cli : les arguments sont séparés par des espaces, et les guillemets simples ou doubles regroupent en un seul ce qui contient des espaces ; entre guillemets doubles, \n, \t et \xHH sont acceptés. Un guillemet resté ouvert n’est pas envoyé, et la sortie dit pourquoi.
L’historique
La flèche haut rappelle la commande précédente quand le curseur est sur la première ligne, et la flèche bas la suivante quand il est sur la dernière ; les boutons Commande précédente de l’historique et Commande suivante de l’historique font de même sans clavier. Il garde les 200 dernières lignes, y compris celles que la console n’a pas exécutées, sans répéter deux fois de suite la même. Effacer vide la sortie, pas l’historique. La sortie, l’historique et ce qui est en cours de saisie sont toujours là quand vous changez d’onglet et revenez.
Lire une réponse
- Un statut comme OK ou PONG s’affiche tel quel.
- Un entier est précédé de (entier).
- Un texte est toujours entre guillemets, avec les caractères de contrôle échappés comme dans redis-cli ("a\r\nb") ; un texte qui n’est pas en UTF-8 s’affiche en hexadécimal, avec sa longueur en octets.
- (nul) signifie l’absence de valeur, et ce n’est pas la même chose que la chaîne vide, qui s’affiche "".
- Une liste est numérotée, et une liste vide affiche (tableau vide). Une table —ce que renvoient HGETALL ou CONFIG GET— s’affiche en paires numérotées champ => valeur. Un ensemble porte un en-tête qui indique combien de membres il a et qu’ils n’ont pas d’ordre, et ses membres sont à puces, sans numéro.
- Une erreur s’affiche en rouge, avec un glyphe et (erreur) devant, et avec le préfixe que lui donne le serveur (WRONGTYPE, ERR…).
- Une réponse de plus de 2000 lignes est coupée, et l’avis renvoie à « Clés », qui parcourt les clés page par page.
Dans un cluster, chaque réponse indique qui a répondu : le primaire du slot de la première clé ou, si la commande n’a pas de clé, le nœud du profil. Une commande sans clé —DBSIZE, INFO— ne compte que ce nœud.
Ce que la console n’exécute pas, et pourquoi
Chaque refus s’affiche dans la sortie avec son motif, et la commande n’atteint jamais le serveur. En dessous, « Ce qu’il ne faut pas faire » ouvre le sujet du Manuel du DBA qui explique pourquoi :
- KEYS parcourt toutes les clés d’un coup et bloque le serveur pendant ce temps. Pour chercher des clés, utilisez « Clés », qui les parcourt page par page avec SCAN.
- MONITOR dégrade le serveur tant qu’il tourne et ne peut pas être arrêté de l’extérieur.
- SUBSCRIBE, PSUBSCRIBE et SSUBSCRIBE feraient arriver les messages du canal mêlés aux réponses des autres commandes. Les canaux actifs et leurs abonnés sont dans « Serveur ».
- SHUTDOWN arrête le serveur.
- DEBUG a des sous-commandes qui figent ou font tomber le serveur (DEBUG SLEEP, DEBUG SEGFAULT).
- RESET et HELLO changent le protocole sous la connexion que Calíope utilise, et CLIENT REPLY OFF ou SKIP cessent de répondre : l’ordre suivant attendrait sa réponse pour toujours. SYNC et PSYNC font de la connexion un lien de réplica, qui reçoit tout ce qui s’écrit sur le serveur.
- SELECT laisserait l’interface afficher une base et en lire une autre : la base se choisit avec le sélecteur de l’outil.
- MULTI, EXEC, DISCARD, WATCH et UNWATCH : une transaction vit sur une seule connexion, et la console envoie chaque ligne par celle qui est libre, si bien que les ordres suivants pourraient partir sur une autre et la transaction resterait ouverte. Pour plusieurs ordres exécutés ensemble, sans rien entre eux, il y a EVAL avec un script.
- Une commande qui attend une donnée —BLPOP, BRPOP, BLMOVE, BZPOPMIN, XREAD … BLOCK, WAIT…— avec un délai de 0, c’est-à-dire une attente sans fin, ou de plus de 10 secondes (plus de 10000 millisecondes dans XREAD BLOCK, WAIT et WAITAOF) : pendant qu’elle attend, elle garde l’une des connexions qu’utilisent tous les outils de la session. Avec un délai plus court, elle s’exécute.
Celles qui demandent de taper leur nom FLUSHDB et FLUSHALL effacent toutes les clés —de la base, ou de toutes les bases— et ne peuvent pas être annulées ; REPLICAOF, SLAVEOF, CLUSTER RESET et CLUSTER FAILOVER changent la topologie, et d’autres clients peuvent perdre l’accès à leurs données. Pour celles-ci, une bande apparaît au-dessus du champ, qui dit ce qui va être effacé ou changé et sur quel serveur, avec un champ où l’on tape le nom de la commande —sans tenir compte des majuscules— et un bouton qui reste inactif tant qu’il n’est pas tapé. Annuler la laisse sans l’envoyer, et la sortie le dit.
Tout le reste s’exécute, y compris EVAL, CONFIG SET et CLIENT KILL. Ce qui s’exécute va dans le journal des commandes, avec le mot de passe d’AUTH masqué.
Cette liste vit dans le code de Calíope, à un seul endroit, et tout chemin qui exécute une commande que vous avez tapée la consulte : si elle change, ce sujet change avec elle.
Ce que montre la topologie d’une session Redis : primaires, répliques et fragments, pourquoi le retard se mesure en octets, ce que sont les slots, ce que veut dire un cluster en échec et pourquoi Sentinel n’y est pas.
Où le trouver : Espace de travail › Outils › Topologie
S'applique à :Redis
La topologie montre comment le serveur de la session est monté. Un cluster s’affiche comme Cluster ; un nœud isolé qui a des répliques, comme Nœud autonome et sa réplication. En haut, un résumé : combien de nœuds et combien de primaires répondent, et ceux qui ne répondent pas, nommés par leur adresse. En dessous, Diagramme dessine une boîte par nœud, regroupées par fragment, avec le primaire en haut et ses répliques en dessous, et Nœuds donne la même chose dans un tableau. Elle se relit toute seule toutes les 5 secondes tant qu’elle est à l’écran, et Actualiser la relit aussitôt.
Le retard se mesure en octets, pas en secondes
Une réplique Redis ne confirme pas une heure : elle confirme jusqu’à quel octet du flux de réplication elle a reçu. La colonne Retard (octets) est donc la position du primaire moins celle de la réplique. Calíope lit le primaire deux fois, avant d’interroger qui que ce soit et à la fin : ce qu’il a avancé entre les deux lectures est le plancher, et en dessous la réplique apparaît À jour, car cet écart ne se distingue pas du temps qu’il faut pour interroger une autre machine. Ce n’est qu’au-dessus qu’elle apparaît En retard. Le lag= que Redis écrit à côté de chaque réplique dans INFO replication est autre chose : les secondes depuis sa dernière confirmation.
Quand un primaire redémarre, il commence un nouveau flux, et sa réplique n’a pas de retard mesurable tant qu’elle ne s’est pas resynchronisée : le tableau indique Sur un autre flux de réplication que son primaire et le retard « non mesuré (autre flux) », au lieu d’afficher 0 octet. Si la réplique a perdu le lien avec son primaire, elle apparaît Liaison avec son primaire coupée.
Les slots
Un cluster répartit les clés sur 16384 slots : chaque clé tombe dans l’un d’eux selon le CRC16 de son nom, et chaque primaire sert une plage. Le nombre est fixe et petit à dessein : la carte de quel primaire sert chaque slot circule entre les nœuds à chaque battement, et doit rester petite. La colonne Emplacements donne la plage de chaque primaire, et le résumé dit combien des 16384 ont un propriétaire.
Quand le cluster échoue
« État du cluster : fail » veut dire que le cluster n’accepte plus de commandes : des slots n’ont plus de primaire vivant pour les servir, parce qu’un primaire est tombé sans réplique pour le remplacer, ou que plusieurs sont tombés à la fois. Un nœud qui ne répond pas apparaît Ne répond pas, avec l’erreur technique à côté, et rien d’autre n’est affirmé à son sujet : ni son rôle ni son retard.
Sentinel n’y est pas
Une session ouverte sur Sentinel n’affiche pas de topologie : Sentinel surveille les primaires et décide du basculement, mais ne stocke pas de données et n’a pas de répliques à lui. Pour voir un primaire avec ses répliques, ouvrez la session sur le primaire.
Avec VoiceOver, le tableau est l’alternative au diagramme : chaque ligne est lue une fois, avec le nom de chaque colonne devant sa valeur.
Ce qu’est un rapport Redis, quels champs il a et ce qu’il coûte au serveur : un parcours des clés à chaque exécution.
Où le trouver : Espace de travail › Outils › Rapports
S'applique à :Redis
Un rapport Redis n’a pas de requête : c’est un parcours des clés transformé en tableau, avec une ligne par clé. On le crée avec Nouveau rapport dans une session Redis, et à la place de l’éditeur de texte apparaissent ses champs.
Ce que vous choisissez Motif est un glob sur le nom de la clé (app:*, session:??, user:[ab]*) ; vide, c’est toutes. Type ne garde que les clés de ce type. Colonnes active key, type, ttl, memory, encoding et length, qui sortent dans l’ordre où vous les activez ; dans Champs de hash, chaque champ, séparé par des virgules, est une colonne de plus avec la valeur de ce champ d’un hash, vide sur une clé qui n’est pas un hash ou qui ne l’a pas. Plafond de lignes dit combien de lignes au maximum ; vide, c’est le plafond du moteur.
Ce que cela coûte
Chaque fois que vous appuyez sur Exécuter, Calíope parcourt avec SCANtoutes les clés qui correspondent au motif — sur un cluster, sur chaque primaire — et seulement ensuite demande les colonnes des lignes gardées. Le plafond coupe les lignes, pas le parcours : avec un motif large sur une base de millions de clés, le rapport prend du temps même s’il en demande dix. Arrêter l’arrête avant la page suivante du parcours.
Le tableau
Les lignes sortent triées par clé, si bien que deux exécutions donnent le même tableau ; s’il y en a plus que le plafond, on garde les premières dans cet ordre, et le tableau indique qu’il a été coupé. memory est ce que répond MEMORY USAGE : sur une collection, c’est une estimation par échantillonnage. Une clé ou un champ qui ne sont pas en UTF-8 sortent comme 0x… avec leur longueur, et leur colonne est marquée comme binaire.
Paramètres
Un paramètre s’écrit $$nom dans le motif et se déclare avec Déclarer les paramètres. Sa valeur est cherchée telle quelle : un * dans la valeur est un astérisque, pas un joker. Elle s’écrit selon son type déclaré, et une valeur qui n’est pas de ce type est refusée avant l’exécution.
Le reste Exporter l’enregistre dans n’importe quel format du menu, PDF compris, et Historique garde chaque exécution, avec ses lignes ou avec son échec. Un rapport Redis ne s’exécute que dans une session Redis : dans une autre, l’outil dit que le rapport n’est pas de cette session et ne le laisse pas exécuter. Planifier ne sert à rien avec lui : seuls les rapports d’une base relationnelle se planifient, et à chaque tour celui de Redis est noté dans l’historique comme Ignoré.