La version du SGBD distribué rqlite 6.0 est présentée, qui utilise SQLite comme moteur de stockage et vous permet d'organiser le travail d'un cluster de stockages synchronisés. L'une des fonctionnalités de rqlite est la facilité d'installation, de déploiement et de maintenance d'un stockage distribué tolérant aux pannes, quelque peu similaire à etcd et Consul, mais utilisant un modèle de données relationnel au lieu d'un format clé/valeur. Le code du projet est écrit en Go et 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 d'origine et le pilote standard go-sqlite3, au-dessus desquels une couche est lancée qui traite les demandes des clients, effectue la réplication vers d'autres nœuds et surveille l'obtention d'un consensus sur le choix d'un nœud leader.
Les modifications apportées à la base de données ne peuvent être apportées que par le nœud sélectionné comme leader, mais les connexions avec des opérations d'écriture peuvent également être envoyées à d'autres nœuds du cluster, qui renverront l'adresse du leader pour répéter la demande (dans la version suivante, ils promesse d'ajouter la transmission automatique des demandes au leader). L'accent principal est mis sur la tolérance aux pannes, de sorte que le SGBD évolue uniquement avec les opérations de lecture, et les opérations d'écriture constituent le goulot d'étranglement. Il est possible d'exécuter un cluster rqlite à partir d'un seul nœud et cette solution peut être utilisée pour fournir un 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 des couches avec la mise en œuvre du protocole Raft, un journal de toutes les commandes SQLite conduisant à des modifications dans la base de données est conservé. Ce journal est utilisé lors de la réplication (réplication au niveau de la reproduction des requêtes sur d'autres nœuds), du démarrage d'un nouveau nœud ou de la récupération après une perte de connectivité. Pour réduire la taille du journal, un packaging automatique est utilisé, qui démarre après un nombre spécifié de modifications et conduit à la fixation d'un instantané sur le disque, par rapport auquel un nouveau journal commence à être conservé (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 :
- Déploiement facile d'un cluster, sans avoir besoin d'une installation SQLite distincte.
- Possibilité d'obtenir rapidement un stockage SQL répliqué.
- Prêt à être utilisé dans des projets de travail (qualité production).
- La présence d'une API HTTP(S) qui permet de mettre à jour les données en mode batch et de déterminer le nœud leader du cluster. Il fournit également une interface de ligne de commande et la possibilité d'utiliser diverses bibliothèques client conçues pour SQLite.
- Disponibilité d'un service d'identification d'autres nœuds, permettant de créer des clusters de manière dynamique.
- Prise en charge du cryptage des échanges de données entre nœuds.
- Possibilité de configurer le niveau de vérification de la pertinence et de la cohérence des données lors de la lecture.
- Possibilité facultative de connecter des nœuds en mode lecture seule, qui ne participent pas à la détermination du consensus et sont utilisés pour augmenter l'évolutivité du cluster pour les opérations de lecture.
- Prise en charge de votre propre forme de transactions basée sur la combinaison de commandes en une seule requête (les transactions basées sur BEGIN, COMMIT, ROLLBACK, SAVEPOINT et RELEASE ne sont pas prises en charge).
- Prise en charge de la création de sauvegardes à chaud.
La nouvelle version introduit des changements architecturaux importants visant à accroître la fiabilité du cluster en améliorant le processus de routage des demandes de lecture et d'écriture vers les nœuds de cluster appropriés. Les nœuds rqlite peuvent désormais multiplexer plusieurs connexions logiques entre eux à l'aide des connexions TCP établies entre les nœuds par le protocole Raft. Si une demande nécessite l'autorité du leader 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 calculs de consensus Raft.
Le changement a également éliminé le besoin d'un composant distinct de synchronisation des métadonnées et a éliminé la gestion séparée de l'état et des métadonnées de Raft. Les nœuds secondaires envoient désormais des requêtes au nœud leader uniquement lorsque cela est nécessaire, lorsqu'ils ont besoin de connaître l'adresse du nœud leader. L'API offre la possibilité d'obtenir des informations sur l'état des autres nœuds du cluster. La commande ".sysdump" a été ajoutée à l'interface de ligne de commande.
Source: opennet.ru