De release van de gedistribueerde DBMS rqlite 6.0 wordt gepresenteerd, die SQLite als opslagengine gebruikt en waarmee u het werk van een cluster van gesynchroniseerde opslag kunt organiseren. Eén van de kenmerken van rqlite is het gemak van installatie, implementatie en onderhoud van een gedistribueerde fouttolerante opslag, enigszins vergelijkbaar met etcd en Consul, maar met behulp van een relationeel datamodel in plaats van een sleutel/waarde-formaat. De projectcode is geschreven in Go en gedistribueerd onder de MIT-licentie.
Om alle knooppunten in een gesynchroniseerde toestand te houden, wordt het Raft-consensusalgoritme gebruikt. Rqlite maakt gebruik van de originele SQLite-bibliotheek en de standaard go-sqlite3-driver, waarbovenop een laag wordt gelanceerd die klantverzoeken verwerkt, replicatie naar andere knooppunten uitvoert en het bereiken van consensus over de keuze van een leidend knooppunt bewaakt.
Wijzigingen in de database kunnen alleen worden aangebracht door het knooppunt dat als leider is geselecteerd, maar verbindingen met schrijfbewerkingen kunnen ook naar andere knooppunten in het cluster worden verzonden, die het adres van de leider retourneren om het verzoek te herhalen (in de volgende versie zullen ze beloven om automatisch doorsturen van verzoeken naar de leider toe te voegen). De nadruk ligt vooral op fouttolerantie, dus het DBMS schaalt alleen met leesbewerkingen, en schrijfbewerkingen vormen het knelpunt. Het is mogelijk om een rqlite-cluster vanaf één enkel knooppunt te laten draaien en deze oplossing kan worden gebruikt om toegang tot SQLite via HTTP te bieden zonder fouttolerantie te bieden.
De SQLite-gegevens op elk knooppunt worden niet in een bestand opgeslagen, maar in het geheugen. Op laagniveau wordt bij de implementatie van het Raft-protocol een log bijgehouden van alle SQLite-opdrachten die tot wijzigingen in de database leiden. Dit logboek wordt gebruikt tijdens replicatie (replicatie op het niveau van het reproduceren van verzoeken op andere knooppunten), het starten van een nieuw knooppunt of het herstellen van een verlies aan connectiviteit. Om de omvang van het logboek te verkleinen, wordt gebruik gemaakt van automatische verpakking, die begint na een bepaald aantal wijzigingen en ertoe leidt dat een momentopname op schijf wordt vastgelegd, in verband waarmee een nieuw logboek wordt bijgehouden (de status van de database in het geheugen is identiek aan de momentopname + het verzamelde wijzigingslogboek).
Kenmerken van rqlite:
- Eenvoudig een cluster te implementeren, zonder dat er een aparte SQLite-installatie nodig is.
- Mogelijkheid om snel gerepliceerde SQL-opslag te verkrijgen.
- Klaar voor gebruik in werkprojecten (productiekwaliteit).
- De aanwezigheid van een HTTP(S) API waarmee u gegevens in batchmodus kunt bijwerken en het leidende knooppunt van het cluster kunt bepalen. Het biedt ook een opdrachtregelinterface en de mogelijkheid om verschillende clientbibliotheken te gebruiken die voor SQLite zijn gebouwd.
- Beschikbaarheid van een service voor het identificeren van andere knooppunten, waardoor u dynamisch clusters kunt maken.
- Ondersteuning voor het coderen van gegevensuitwisseling tussen knooppunten.
- Mogelijkheid om het niveau van controle van de relevantie en consistentie van gegevens tijdens het lezen te configureren.
- Optionele mogelijkheid om knooppunten in alleen-lezen-modus te verbinden, die niet deelnemen aan het bepalen van consensus en worden gebruikt om de schaalbaarheid van het cluster voor leesbewerkingen te vergroten.
- Ondersteuning voor uw eigen transactievorm op basis van het combineren van opdrachten in één verzoek (transacties op basis van BEGIN, COMMIT, ROLLBACK, SAVEPOINT en RELEASE worden niet ondersteund).
- Ondersteuning voor het maken van actieve back-ups.
De nieuwe release introduceert belangrijke architecturale veranderingen die gericht zijn op het vergroten van de clusterbetrouwbaarheid door het proces van het routeren van lees- en schrijfverzoeken naar de juiste clusterknooppunten te verbeteren. rqlite-knooppunten kunnen nu meerdere logische verbindingen onderling multiplexen met behulp van TCP-verbindingen die tussen knooppunten tot stand zijn gebracht door het Raft-protocol. Als een verzoek leiderschapsautoriteit vereist, maar naar een secundair knooppunt wordt verzonden, kan het secundaire knooppunt het adres van de leider bepalen en dit doorgeven aan de klant zonder Raft-consensusberekeningen uit te voeren.
De verandering elimineerde ook de noodzaak van een afzonderlijke component voor de synchronisatie van metadata en elimineerde de afzonderlijke verwerking van de Raft-status en metadata. Secundaire knooppunten sturen nu alleen verzoeken naar het leiderknooppunt als dat nodig is, wanneer ze het adres van het leiderknooppunt moeten achterhalen. De API biedt de mogelijkheid om informatie te verkrijgen over de status van andere knooppunten in het cluster. De opdracht ".sysdump" is toegevoegd aan de opdrachtregelinterface.
Bron: opennet.ru