Cette page décrit Calíope 1.5, la version que je construis en ce moment. La 1.4 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.
Affiche l'état en temps réel de SHOW REPLICA STATUS : délai, threads I/O et SQL, erreurs et position dans le journal binaire.
Où le trouver : Espace de travail › Outils › Moniteur de réplication
Le Moniteur de réplication affiche SHOW REPLICA STATUS (SHOW SLAVE STATUS avant MariaDB 10.5 et MySQL 8.0.22) du serveur auquel vous êtes connecté, et le relit toutes les 5 secondes.
Comment ouvrir le moniteur :
Dans la barre latérale Outils, cliquez sur Moniteur de réplication (icône de flèches circulaires). Le moniteur s'ouvre dans un nouvel onglet.
Indicateurs principaux :
- Thread IO : le thread qui lit les événements du serveur source. Il affiche ce que dit le serveur — Yes, No ou Connecting — et n'est vert qu'avec Yes.
- Thread SQL : le thread qui applique ces événements sur ce serveur, avec les mêmes valeurs.
- Retard : secondes de retard par rapport au serveur source.
- Vert — moins de 5 s
- Orange — de 5 s à 30 s
- Rouge — 30 s ou plus
Avec un thread arrêté, le serveur n'a pas de chiffre et la carte indique Pas de mesure : un zéro dirait « à jour » d'une réplique qui n'applique rien.
- Serveur source : l'hôte depuis lequel cette réplique lit.
- Position du journal binaire : le fichier du journal binaire de la source, la position jusqu'à laquelle le thread IO a lu et celle que le thread SQL a exécutée. Tant que les deux diffèrent, il y a des événements reçus et pas encore appliqués.
Erreurs : si un thread s'arrête sur une erreur, une section Erreurs de réplication apparaît avec le message complet du serveur.
Statut complet : toutes les colonnes de SHOW REPLICA STATUS avec leur valeur brute, y compris celles que les cartes n'affichent pas : les positions GTID, Master_Server_Id (la machine depuis laquelle lit cette réplique) ou le retard configuré.
Actualisation automatique : l'interrupteur Actualisation auto (5 s) lit le statut toutes les 5 secondes, et Mis à jour indique quand il a été lu pour la dernière fois. Désactivez-le pour garder une lecture figée, et cliquez sur Actualiser pour le relire quand vous voulez.
Alertes de retard : si le retard atteint le seuil configuré dans Alertes du serveur (voir le sujet Alertes du serveur), une notification système est envoyée.
Le moniteur ne fait que lire : il ne démarre ni n'arrête la réplication. Sur un serveur qui n'est pas une réplique — un primaire ou un serveur autonome — il affiche Le serveur n'est pas un réplicat à la place des cartes.
Le groupe entier d’un coup d’œil, pas une machine vue de l’intérieur.
Où le trouver : Espace de travail › Outils › Topologie
Il coexiste avec le Moniteur de réplication et ne le remplace pas : celui-ci montre l’état de la machine à laquelle vous êtes connecté, vue de l’intérieur ; celui-là parle à toutes les machines du groupe, y compris celles que vous n’avez pas ouvertes, et ne fait que lire.
Quelle machine est le primaire et lesquelles sont les répliques, c’est vous qui le déclarez. Ce n’est pas détecté : la détection ne verrait que ce qui est connecté à l’instant, produirait des groupes qui changent tout seuls, et vous ne pourriez pas distinguer « cette réplique n’est plus dans le groupe » de « cette réplique est en panne ».
En revanche, elle vous contredit : si le primaire ne voit pas une réplique déclarée, ou si une réplique pointe vers un autre serveur, on vous le dit.
Qu’un membre ne réponde pas est un état normal du groupe, pas une erreur : vous verrez « 7 sur 9 joints », avec les deux manquants nommés et leur motif.
« Secondes de retard » ment dans deux cas, d’où la dérive de GTID à côté.
Où le trouver : Topologie › Retard
Seconds_Behind_Source mesure l’événement en cours d’application, pas ce qu’il reste à appliquer. D’où deux façons de tromper :
- Avec le thread IO arrêté, le serveur n’a rien pour le calculer et renvoie nul. Ici vous verrez « Pas de mesure », pas un zéro : un zéro dirait « à jour » d’une réplique déconnectée.
- Une réplique qui vient de se reconnecter après une longue coupure peut afficher 0 alors qu’il lui reste des heures de binlog à récupérer, simplement parce que l’événement qu’elle applique à cet instant est récent.
C’est pourquoi la dérive de GTID est juste à côté : combien de transactions le primaire possède que la réplique n’a pas exécutées. Ce chiffre-là dit ce qui manque. Quand la réplication se fait par position de binlog et non par GTID, il n’y a rien à comparer, et c’est dit aussi.
Vous choisissez parmi vos connexions enregistrées laquelle est la primaire et lesquelles sont les répliques.
Où le trouver : Topologie › Déclarer des groupes
Un groupe se déclare depuis l’outil lui-même : le bouton Déclarer des groupes de sa barre. Ce n’est pas dans la configuration du moniteur de serveurs, qui est un autre outil avec un autre interrupteur.
Les membres viennent de vos connexions enregistrées : vous en choisissez une comme primaire et ajoutez les autres comme répliques, dans l’ordre où vous voulez les voir. Il faut au moins deux connexions enregistrées — une pour la primaire et une pour sa réplique ; si vous ne les avez pas, enregistrez-les d’abord dans le gestionnaire de connexions.
Seules les connexions vers un moteur dont l’outil sait sonder la réplication sont proposées ; les autres n’apparaissent pas dans la liste. Si un membre déjà enregistré ne peut plus être sondé, le groupe continue de l’afficher, non joint et avec le motif.
Calíope ne devine pas la topologie : la détection ne verrait que ce qui est connecté à l’instant présent, les groupes changeraient donc tout seuls et vous ne pourriez pas distinguer « cette réplique n’est plus dans le groupe » de « cette réplique est tombée ». En revanche, il vous contredit lorsque la primaire ne voit pas une réplique que vous avez déclarée.
Chaque groupe a son propre intervalle de sondage et son propre interrupteur : l’éteindre arrête le sondage sans effacer la topologie. Et si vous supprimez une connexion qui était membre, le groupe ne disparaît pas — il est signalé, et on vous dit quels membres ont été retirés.
Lisez le journal binaire du serveur événement par événement, filtré par classe (DDL, DML, Système) et par texte.
Où le trouver : Espace de travail › Outils › Journal binaire
Le journal binaire est le registre que tient le serveur de chaque modification : ce que copient les répliques et ce que rejoue une restauration à un instant donné. La visionneuse le lit depuis l'application, sans l'utilitaire mysqlbinlog en ligne de commande.
Comment l'ouvrir :
Dans la barre latérale Outils, cliquez sur Journal binaire (icône de parchemin). Il s'ouvre dans un nouvel onglet et lit aussitôt le fichier le plus récent.
Utilisation :
1. Fichier : liste les fichiers du journal binaire du serveur (SHOW BINARY LOGS) avec leur taille. En choisir un lit ses événements.
2. Limite est le nombre d'événements lus, depuis le début du fichier (de 100 à 2000). La changer relit le fichier. Si le fichier contient davantage d'événements, une ligne au-dessus de la liste le signale : augmentez la limite pour lire plus loin.
3. Type filtre par classe : Tous, DDL, DML ou Système.
4. Le champ Rechercher… garde les événements dont le type ou le contenu contient le texte.
5. Recharger les journaux relit la liste des fichiers et, avec elle, le fichier choisi : c'est ainsi qu'on voit les modifications faites depuis l'ouverture de l'onglet. Si vous lisiez le fichier le plus récent et que le serveur en a commencé un autre, la visionneuse passe au nouveau.
Classes d'événements :
- DDL (orange) : les instructions qui modifient le schéma ou les comptes — CREATE, ALTER, DROP, RENAME, TRUNCATE, GRANT, REVOKE.
- DML (bleu) : les modifications de données. Avec la journalisation par lignes, une modification est un groupe : l'instruction qui l'a produite (Annotate_rows dans MariaDB, Rows_query dans MySQL, si le serveur l'enregistre), la table touchée (Table_map) et les lignes (Write_rows, Update_rows, Delete_rows). Avec la journalisation par instructions, l'INSERT, l'UPDATE, le DELETE, le REPLACE ou le LOAD DATA lui-même.
- Système (gris) : tout ce qui n'est pas une modification — BEGIN, la validation (Xid), Gtid, Rotate, l'en-tête du fichier (Format_desc), les autres événements de contrôle, et les instructions qui ne modifient ni les données ni le schéma, comme FLUSH PRIVILEGES.
Chaque ligne affiche :
le type d'événement, sa position de début (Pos) et, si le serveur l'enregistre, celle de fin ; sa classe ; et le champ Info : le SQL d'une instruction, la table d'un Table_map, le numéro de transaction d'une validation.
Cas d'usage :
- Audit des modifications : quel DDL a été exécuté, et dans quel ordre.
- Analyse de la réplication : ce que copient les répliques.
- Restauration à un instant donné : la position exacte jusqu'à laquelle restaurer.
La visionneuse ne fait que lire : elle ne purge ni ne modifie aucun journal binaire.
Privilèges requis :
- MariaDB 10.5 et suivantes : BINLOG MONITOR.
- MySQL : REPLICATION CLIENT pour lister les fichiers et REPLICATION SLAVE pour lire leurs événements.
Sans eux, ou si le journal binaire est désactivé, la visionneuse indique qu'elle n'y a pas accès.