SynSql permet de stocker chaque table en un deux ou trois exemplaires. Le choix se fait lors de la conception de la table, via une commande spécifique: alter table TableName set replicates 1|2|3.
La mise en oeuvre se fait pendant la phase de déploiement. Elle consiste à créer un, deux ou trois segments pour chaque partition.
Les segments d'une table qui portent des données correspondant à la même valeur de la fonction de hachage sont dits homologues.
Pour garantir que des segments homologues contiennent les mêmes données, SynSql force l'exécution de toute requête de modification de données sur tous les segments concernés.
Quand une requête échoue sur un segment, le statut de ce segment passe de "sain" à "dégradé".
Un segment dégradé n'est plus synchronisé, il n'est plus utilisable et sera ignoré par toutes les requêtes suivantes, jusqu'à réparation.
Une désynchronisation a deux causes possibles:
- Le data broker qui portait le segment a eu un incident.
- Le data broker qui portait le segment devait subir une intervention qui allait le rendre indispobible. L'administrateur l'a placé hors ligne.
Tant qu'une table possède au moins un segment sain par partition, toutes les opérations sont possibles. Par contre, si une partition de table voit tous ses segments homologues dégradés:
- Il n'est plus possible d'insérer des données dans cette partition, mais on peut insérer dans toutes celles qui ont au moins un segment sain.
- Tout ordre select/truncate sur la table échoue.
L'instruction drop table est acceptée quel que soit l'état de la table. Si une table est supprimée alors qu'elle possedait des segments sur un data broker hors ligne, ces segments deviennent orphelins.
La resynchronisation n'a de sens que pour des tables qui possèdent plusieurs exemplaires. Elle suppose aussi que la cause de la désynchronisation a trouvé une solution.
La resynchronisation de segments se fait table par table, via l'instruction spécifique repair table. Elle conduit le synsql broker qui la reçoit à parcourir la liste des segment dégradés de la table et à restaurer chacun d'entre eux à l'aide d'un homologue sain.
Avant de réparer une table vous devez la verrouiller pour garantir le résultat.
Une table dont tous les homologues d'une partition sont dégradés n'est pas réparable.
Notez par contre que, si un incident sur un broker à conduit à sa disparition physique, il est possible de le remplacer par un nouveau serveur. Ce dernier devra reprendre les caractéristiques du premier : nom, adresse, database, utilisateur, mot de passe, etc. Mais il n'est pas nécessaire de recrééer les segments. Ils seront recréés automatiquement par la réparation des tables.
Quand une intervention sur un data broker est terminée et que celui-ci est de nouveau disponible, l'administrateur utilise une instruction spécifique SynSql pour le remettre en ligne : alter data broker XXX set online [force].
Cette déclaration ne resynchronise pas les segments dégradés qu'il porte. Ils resteront dégradés jusqu'à leur réparation. Ceux sont restés sains redeviennent utilisables du simple fait de la disponibilité du data broker.
La remise en ligne impacte en fait les segments orphelins. S'il en existe l'intruction de remise en ligne ne sera acceptés qu'avec l'option "force" qui va provoquer leur suppression. A défaut, le data broker reste hors ligne.
Il est important de noter que la réplication SynSql se fait à la hauteur des segments, pas à celle des tables. Si un segment voit un de ses homologues se faire dégrader, la perte ne concerne que la partition des segments en question. Elle ne concerne pas les autres partitions.
Dans un cluster SynSql, la notion d'image n'a pas de sens pour une table.
| 15 Jan 2026 07:20:11 | English version |