Documentation > Guide de l'administrateur
En cas d'incident sur un des serveur d'un cluster SynSql, les autres serveurs s'adaptent automatiquement pour continuer de produire le service des données. C'est aussi le cas lorsqu'un administrateur veut stopper un serveur le temps d'une intervention.
Lorsque qu'incident est résolu ou quand un serveur est de retour en service, c'est l'administrateur qui doit réaliser différentes actions pour remettre le cluster en condition optimale. Les paragraphes ci-dessous décrivent ces actions en fonction de la panne subie.
Quand un synsql broker échoue à se connecter à un master broker pour une opération de lecture, il ignore silencieusement l'erreur et tente de se connecter au master broker suivant, dans une liste qu'il maintient en mémoire. S'il ne parvient pas à se connecter à un autre master broker, il se termine et la situation est comparable à celle décrite au paragraphe 2.2 ci-dessous.
Si l'erreur survient alors que le synsql broker devait réaliser une écriture (une modification du dictionnaire données) il ne peut pas ignorer l'erreur. Il supprime le master broker de la liste en mémoire et signale le fait à tous les autres synsql brokers pour qu'ils fassent de même.
Lorsqu'un synsql broker constate la perte du dernier master broker, il se termine parce qu'il n'a plus aucun moyen de fonctionner. Si vous ne parvenez pas à relancer le dernier master broker, le cluster est perdu.
La mise en place d'une sauvegarde de type mysqldump sur les différents master brokers du cluster est illusoire : Dès lors qu'un objet est créé, modifié ou supprimé, toute sauvegarde précédente d'un master broker devient obsolète. La sauvegarde des master brokers tient en leur multiplicité. Il est de la responsabilité de l'administrateur de faire en sorte que tout cluster dispose d'un minimum de deux master brokers.
Certaines versions payantes des logiciels que vous pouvez utiliser pour porter vos master brokers permettent de sauvegarder les journaux de transaction en continu. A la suite d'un crash fatal, cela permet en général de restaurer les bases de données jusqu'à la dernière transaction commitée. Si votre cluster de production contient des données sensibles nous vous recommandons vivement d'utiliser ces mécanismes.
Tant qu'il reste au moins un autre master broker actif, la perte d'un master broker n'interrompt pas le cours du cluster qui peux continuer de fonctionner.
Par contre, il faut bien noter qu'un master broker marqué comme inutilisable se retrouve désynchronisé dès lors que les master brokers restants enregistrent des modifications du dictionnaire.
Pour revenir en situation nominale après la perte d'un master broker, il y a deux solutions.
- S'il est possible de relancer le service de base de données du data broker concerné, alors un reboot du cluster va forcer sa resynchronisation.
- Si le master broker est perdu, vous pouvez le supprimer avant d'en recréer un autre. Notez que la suppression d'un master broker est impossible si tous les synsql brokers du cluster ne sont pas lancés.
La perte d'un data broker n'a en général que peu d'impact. Les segments qu'il porte ne sont plus accessibles et au fur et à mesure que différentes requêtes échoueront à les lire ou écrire, ils seront marqués comme désynchronisés.
Tant qu'une table possède au moins un segment en ligne pour chacune de ses partitions, elle peut être utilisée normalement. Les tables sont donc d'autant plus résilientes qu'elles ne possèdent d'exemplaires. Une table qui par contre ne possède plus aucun segment disponible pour l'une de ses partitions devient inutilisable et cette situation peut conduire à des désynchronisations.
Pour réduire ce risque, il faut traiter toute perte de data broker rapidement.
Note : toute table qui ne comportait qu'un seul exemplaire et qui contenait un segment sur le broker perdu est elle même perdue.
Il faut commencer par déclarer la perte du broker. via l'instruction suivante :
alter databroker NomDuBroker set lost;
Cette instruction ne supprime pas la définition du data broker ni des segments qu'il porte. Elle indique simplement au cluster que le data broker est hors ligne mais surtout que tous les segments qu'il portait sont désynchronisés.
Il faut créer un nouveau serveur qui va reprendre le nom et l'adresse IP du borker perdu. Il faut ensuite installer un service de base de données, recréer la database et l'utilisateur à l'identique. Il est totalement inutile de tenter de restaurer les tables que l'ancien serveur portait.
Une fois le nouveau service disponible il faut le déclarer online :
alter databroker NomDuBroker set online;
Cette instruction a pour effet de déclarer que le data broker est de nouveau disponible. Et puisque le serveur est disponible, il est possible de resynchroniser les tables qui possèdent des segments sur le data broker. Pour chacune des tables possédant un segment sur le data broker concerné, il faut exécuter l'instruction suivante :
repair table NomDeLaTable;
Elle aura pour effet de :
- Déterminer ne numéro de la partition du segment que le data broker portait et qui n'existe plus.
- Déterminer quel segment homologue permet de restaurer le segment perdu.
- Recréer le le segment et resynchroniser son contenu à l'aide de l'homologue.
Il faut distinguer arrêt et perte. Un arrêt est une demande ordinaire qui peut être faite alors que des utilistauers cont connectés au serveur. Cela ne provoque jamais l'interruption d'une instruction de définition de données en cours. Si un synsql broker doit se terminer alors qu'une création de table est en cours, la création ira à son terme. Par contre, l'arrêt d'un synsql broker pendant l'exécution d'une requête de selection interrompt cette requête.
La perte d'un synsql broker peut intervenir à tout instant. En particulier dans une phase où une création de table est en cours. Cela pourra conduire à la création de la table sur les premiers master brokers de la liste du synsql broker mais pas sur les derniers. Dans ce cas, les master brokers sont désynchronisés et il faudra procéder à une resynchronisation manuelle.
Si le dernier synsql broker actif cesse de fonctionner, le cluster est stoppé. Tant que le cluster restera stoppé, les processus clients se termineront à la prochaine demande d'exécution de requête.
La relance d'un seul des synsql brokers du cluster suffira pour le relancer. Les clients qui n'auront eu aucune activité entre la perte du dernier synsql broker et la relance du cluster se reconnecteront automatiquement au nouveau broker.
Si vous rencontrez une erreur fatale, si une requête retourne des résultats incohérents et si vous utilisez une license autre que 'Tiny' vous pous faire une demande d'assistance par email à admin@synsql.com
Pour que nous puissions traiter correctement votre demande, il faut nous fournir les éléments suivants :
- l'uuid de votre cluster,
- La liste des requêtes qui conduisent à l'erreur,
- La définition des tables qui sont impliquées dans les requêtes,
- Un jeu d'essai suffisant pour analyser l'erreur,
- Le log du serveur en mode debug.
| 15 Jan 2026 07:12:45 | English version |