SynSql propose un partitionnement systématique des tables et permet de stocker les données en un deux ou trois exemplaires. Une table distribuée sur 250 partitions et stockée en deux exemplaires possédera 500 segments. Chacun de ces segment sera stocké sur un data broker dédié. Un même data broker ne peut pas stocker deux segments distincts d'une même table.
Lors de l'édition d'une donnée (création, modification ou supression) si un data broker ne répond pas, il est marqué comme étant hors service. Si l'opération a échoué sur un segment mais pas sur son ou ses homologues, le segment est déclaré périmé. Tant qu'une table possède au moins un segment sain pour chaque partition et que ces segments sont sur des serveurs en service, elle peut faire l'objet de tout type de requête. Si la situation est plus grave, les requêtes de modification de données refuseront de s'exécuter.
SynSql propose des commandes pour gérer le statut des data brokers. Quand un data broker revient en service, il est possible de resynchroniser les segments périmés qu'il porte à partir d'un homologue sain.
Comme tout système de gestion de données relationnelles, SynSql comporte un dictionnaire des données. Il contient la définition des tables, des utilisateurs, des data brockers, etc. SynSql utilise des serveurs de données dédiés pour stocker son dictionnaire : ce sont les master brokers. Ils sont gérés en miroir. Si l'un d'entre eux cesse de fonctionner, il est simplement supprimé de la liste gérée par le cluster. Il est aussi possible de créer et déclarer un nouveau master broker à la volée.
SynSql permet d'exécuter jusqu'à 32 synsql brokers sur des serveurs différents.
Si un client SynSql détecte que le serveur auquel il était connecté a cessé de fonctionner, que se soit un incident ou non, il va tenter de se reconnecter automatiquement. Soit au même serveur, qui peut avoir été relancé depuis, soit à un autre serveur du cluster. Tant qu'un serveur accepte la reconnexion, le client continue le service.
| 15 Jan 2026 04:14:48 | English version |