Cette page décrit Calíope 1.5, la version que nous construisons en ce moment. La 1.4 est terminée et en cours d'examen par Apple, et la boutique propose aujourd'hui la 1.3 sur le Mac et la 1.2 sur iPad. 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 › Réplique
Le Moniteur de réplication interroge automatiquement SHOW REPLICA STATUS (ou SHOW SLAVE STATUS pour les versions antérieures à MySQL 8.0.22) toutes les 5 secondes.
Comment ouvrir le moniteur :
Dans la barre latérale Outils, cliquez sur Réplica (icône de flèches circulaires). Le moniteur s'ouvre dans un nouvel onglet.
Indicateurs principaux :
- I/O Thread : état du thread qui lit les événements depuis le serveur source (Running / Not Running).
- SQL Thread : état du thread qui applique les événements localement (Running / Not Running).
- Délai : secondes de retard par rapport au serveur source.
- Vert — délai < 5 s (synchronisé)
- Orange — délai entre 5 s et 30 s (retard modéré)
- Rouge — délai ≥ 30 s (retard critique)
- Serveur source : hôte du serveur maître/source de données.
- Position dans le journal binaire : fichier et position du journal binaire lus par le thread I/O, et position exécutée par le thread SQL.
Erreurs : si le thread I/O ou SQL présente des erreurs, elles s'affichent en rouge avec le message d'erreur MySQL complet.
Actualisation automatique : le bouton Actualisation auto (5 s) active la mise à jour automatique toutes les 5 secondes. Désactivez-le si vous souhaitez une lecture statique pour inspecter les valeurs sans qu'elles changent.
Alertes de délai : si un délai de réplication supérieur au seuil configuré dans Alertes du serveur est détecté (voir le sujet Alertes du serveur), une notification système est envoyée.
Ce panneau n'affiche des données utiles que si le serveur MySQL connecté est configuré comme réplica. Sur un serveur maître ou autonome, les valeurs apparaîtront sous la forme —.
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é et permet de la démarrer, l’arrêter ou la réinitialiser ; 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.
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.
Explorez les événements du journal binaire MySQL avec des filtres par type (DDL, DML, Système) et une recherche par texte.
Où le trouver : Espace de travail › Outils › Binlog
Le journal binaire de MySQL enregistre toutes les modifications de données sur le serveur. La visionneuse de Calíope vous permet d'explorer ces événements directement depuis l'application, sans avoir besoin d'utiliser l'utilitaire mysqlbinlog en ligne de commande.
Comment ouvrir la visionneuse :
Dans la barre latérale Outils, cliquez sur Binlog (icône de parchemin). La visionneuse s'ouvre dans un nouvel onglet.
Utilisation :
1. Sélectionnez le fichier journal dans le sélecteur de la barre supérieure. Les fichiers disponibles sont récupérés avec SHOW BINARY LOGS.
2. Ajustez la Limite d'événements à charger (utile pour les journaux très volumineux).
3. Appuyez sur Charger pour lire les événements du fichier sélectionné.
4. Filtrez par type d'événement à l'aide des boutons : Tous, DDL, DML ou Système.
5. Utilisez le champ de recherche pour filtrer les événements par contenu du champ Info.
Types d'événements :
- DDL (orange) : instructions CREATE, ALTER, DROP, RENAME dans les événements Query.
- DML (bleu) : événements de lignes — Write_rows, Update_rows, Delete_rows.
- Système (gris) : Xid (commit de transaction), Gtid, Rotate, Anonymous_Gtid et autres événements de contrôle.
Informations par événement :
Chaque ligne affiche le fichier journal, la position de début, le type d'événement, la position de fin et le champ Info avec le contenu de l'événement (SQL pour DDL, description des lignes pour DML).
Cas d'utilisation :
- Audit des modifications en production : voir quelles instructions DDL ont été exécutées et quand.
- Analyse de la réplication : vérifier que les événements sont générés correctement.
- Récupération à un instant précis (point-in-time recovery) : identifier la position exacte dans le binlog jusqu'à laquelle restaurer.
Exigences de privilèges :
- BINLOG_MONITOR (MariaDB 10.5+ ou MySQL 8.0.22+)
- REPLICATION SLAVE pour les versions antérieures de MySQL