Publication de rqlite 6.0, une base de données distribuée tolérante aux pannes basée sur SQLite.

La version 6.0 de la base de données distribuée rqlite a été présentée, utilisant SQLite comme moteur de stockage et permettant l'organisation d'un cluster de dépôts synchronisés. Parmi les caractéristiques de rqlite, on note la simplicité d'installation, de déploiement et de maintenance d'un stockage distribué tolérant aux pannes, similaire à etcd et Consul, mais utilisant un modèle relationnel pour le travail avec les données au lieu d'un format clé/valeur. Le code du projet est écrit en Go et est distribué sous licence MIT.

Pour maintenir tous les nœuds dans un état synchronisé, l'algorithme de consensus Raft est utilisé. Rqlite utilise la bibliothèque SQLite originale et le driver standard go-sqlite3, sur lesquelles repose une couche qui traite les requêtes des clients, effectue la réplication vers d'autres nœuds et suit l'atteinte du consensus sur le choix du nœud leader.

Les modifications dans la base de données peuvent être apportées uniquement par le nœud désigné comme leader, mais les connexions pour les opérations d'écriture peuvent également être dirigées vers d'autres nœuds du cluster, qui retourneront l'adresse du leader pour réitérer la requête (la prochaine version promet d'ajouter un passage automatique à travers le leader). L'accent est mis sur la tolérance aux pannes, donc le SGBD ne se développe que pour les opérations de lecture, tandis que les opérations d'écriture représentent un goulot d'étranglement. Il est possible de lancer un cluster rqlite à partir d'un seul nœud, et cette solution peut être utilisée pour organiser l'accès à SQLite via HTTP sans fournir de tolérance aux pannes.

Les données SQLite sur chaque nœud ne sont pas stockées dans un fichier, mais en mémoire. Au niveau de la couche d'implémentation du protocole Raft, un journal de toutes les commandes SQLite qui entraînent des modifications de la base de données est conservé. Ce journal est utilisé lors de la réplication (réplication au niveau de la lecture des requêtes sur d'autres nœuds), du lancement d'un nouveau nœud ou de la récupération après une perte de connectivité. Pour réduire la taille du journal, une compression automatique est appliquée, qui est lancée après un certain nombre de modifications et entraîne la sauvegarde sur disque d'un instantané, à partir duquel un nouveau journal commence à être tenu (l'état de la base de données en mémoire est identique à l'instantané + le journal des modifications accumulées).

Caractéristiques de rqlite :

• Simplicité de déploiement du cluster, sans nécessiter d'installation séparée de SQLite.
• Possibilité d'obtenir rapidement un stockage SQL répliqué.
• Prêt à être utilisé dans des projets de production.
• La disponibilité d'une API HTTP(S) permettant de mettre à jour les données en mode batch et de déterminer le nœud principal du cluster. Une interface en ligne de commande est également fournie, ainsi que la possibilité d'utiliser diverses bibliothèques clientes conçues pour SQLite.
• Disponibilité d'un service pour identifier d'autres nœuds, permettant de créer des clusters de manière dynamique.
• Support du chiffrement des échanges de données entre les nœuds.
• Possibilité de configurer le niveau de vérification de l'actualité et de la cohérence des données lors de la lecture.
• Possibilité optionnelle de connecter des nœuds en mode lecture seule, ne participant pas à la détermination du consensus et utilisés pour augmenter la scalabilité du cluster pour les opérations de lecture.
• Support d'une forme propre des transactions basée sur la fusion de commandes dans une seule requête (les transactions basées sur BEGIN, COMMIT, ROLLBACK, SAVEPOINT et RELEASE ne sont pas supportées).
• Support de la création de sauvegardes à chaud.

La nouvelle version apporte des modifications architecturales significatives visant à améliorer la fiabilité du cluster grâce à l'optimisation du routage des requêtes de lecture et d'écriture vers les nœuds appropriés du cluster. Les nœuds rqlite peuvent désormais multiplexe entre plusieurs connexions logiques en utilisant des connexions TCP établies entre les nœuds par le protocole Raft. Si une requête nécessite les droits du nœud principal mais est envoyée à un nœud secondaire, le nœud secondaire peut déterminer l'adresse du leader et la transmettre au client, sans effectuer de calcul de consensus via le protocole Raft.

Le changement a également permis de se débarrasser d'un composant distinct pour la synchronisation des métadonnées et d'éliminer le traitement séparé de l'état Raft et des métadonnées. Les nœuds secondaires dirigent désormais les requêtes vers le nœud principal uniquement si nécessaire, lorsqu'il leur faut connaître l'adresse du nœud principal. L'API propose la possibilité d'obtenir des informations sur l'état des autres nœuds du cluster. Une commande « .sysdump » a été ajoutée à l'interface de ligne de commande.

Source : opennet.ru