{"id":100516,"date":"2021-06-14T16:22:58","date_gmt":"2021-06-14T14:22:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite"},"modified":"2021-06-14T16:22:58","modified_gmt":"2021-06-14T14:22:58","slug":"vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite","title":{"rendered":"Uitgave van rqlite 6.0, een gedistribueerd fault-tolerant databasebeheersysteem gebaseerd op SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
De release van de gedistribueerde database rqlite 6.0 is ge\u00efntroduceerd, die SQLite gebruikt als opslagengine en de werking van een cluster van gesynchroniseerde opslagplaatsen mogelijk maakt. Onder de kenmerken van rqlite valt de eenvoud van installatie, implementatie en onderhoud van een gedistribueerde fault-tolerante opslag, die lijkt op etcd en Consul, maar gebruikmaakt van een relationeel datamodel in plaats van een sleutel\/waarde-formaat. De code van het project is geschreven in Go en wordt verspreid onder de MIT-licentie. <\/p>\n
Om alle knooppunten in een gesynchroniseerde toestand te houden, wordt het Raft-consensusalgoritme gebruikt. Rqlite gebruikt de originele SQLite-bibliotheek en de standaard go-sqlite3-driver, waarboven een laag draait die de klantverzoeken verwerkt, replicatie naar andere knooppunten uitvoert en de consensus voor de keuze van een leidend knooppunt volgt. <\/p>\n
Wijzigingen in de database kunnen alleen worden aangebracht door het knooppunt dat als leidend is gekozen, maar verbindingen met schrijfbewerkingen kunnen ook naar andere knooppunten in het cluster worden gestuurd, die het adres van de leider teruggeven voor het herhalen van de aanvraag (in de volgende versie beloven ze automatisch door te sturen naar de leider). De belangrijkste focus ligt op fault-tolerance, daarom schaalt de database alleen op leesbewerkingen, terwijl schrijfbewerkingen de bottleneck zijn. Het is mogelijk om een rqlite-cluster te draaien vanuit \u00e9\u00e9n knooppunt en deze oplossing kan worden gebruikt voor toegang tot SQLite via HTTP zonder fault-tolerance te bieden. <\/p>\n
De SQLite-gegevens op elk knooppunt worden niet in een bestand, maar in het geheugen opgeslagen. Op het niveau van de laag met de implementatie van het Raft-protocol wordt een log van alle SQLite-opdrachten die de database wijzigen bijgehouden. Deze log wordt gebruikt bij replicatie (replicatie op het niveau van het reproduceren van aanvragen op andere knooppunten), het opstarten van een nieuw knooppunt of het herstel na verbindingsverlies. Voor het verkleinen van de loggrootte vindt automatische compressie plaats, die wordt gestart na een vastgesteld aantal wijzigingen en leidt tot het vastleggen van een snapshot op de schijf, waartegen een nieuwe log wordt bijgehouden (de toestand van de database in het geheugen is identiek aan het snapshot + de cumulatieve log van wijzigingen). <\/p>\n
Kenmerken van rqlite: <\/p>\n
\n
Eenvoudige uitrol van een cluster, zonder aparte installatie van SQLite.\n
De mogelijkheid om snel een gerepliceerde SQL-opslag te krijgen.\n
Klaar voor gebruik in productiewerkzaamheden (productieklaar).\n
Beschikking over een HTTP(S) API die batchupdates van gegevens mogelijk maakt en het mogelijk maakt om de leidende knoop van het cluster te bepalen. Er is ook een opdrachtregelinterface en de mogelijkheid om verschillende clientbibliotheken te gebruiken die voor SQLite zijn gemaakt.\n
Aanwezigheid van een service voor het bepalen van andere knooppunten, waardoor dynamisch clusters kunnen worden gemaakt.\n
Ondersteuning voor het versleutelen van gegevensuitwisseling tussen knooppunten.\n
Mogelijkheid om het niveau van actualiteits- en consistentiecontrole van gegevens tijdens het lezen in te stellen.\n
Optionele mogelijkheid om knooppunten in alleen-lezen modus aan te sluiten, die niet deelnemen aan het bepalen van de consensus en worden gebruikt om de schaalbaarheid van het cluster voor leesoperaties te vergroten.\n
Ondersteuning voor een eigen transactievorm op basis van het groeperen van commando's in \u00e9\u00e9n aanvraag (transacties op basis van BEGIN, COMMIT, ROLLBACK, SAVEPOINT en RELEASE worden niet ondersteund).\n
Ondersteuning voor het maken van hot backups. <\/ul>\n
In de nieuwe release zijn aanzienlijke architectonische wijzigingen aangebracht om de betrouwbaarheid van het cluster te verbeteren door het proces van het leiden van lees- en schrijfvraagstukken naar de juiste knooppunten in het cluster te verbeteren. Rqlite-knooppunten kunnen nu meerdere logische verbindingen multiplexen via TCP-verbindingen die tussen de knooppunten zijn ingesteld via het Raft-protocol. Als een aanvraag de bevoegdheden van de leidende knoop vereist, maar naar een secundaire knoop is verzonden, kan de secundaire knoop het adres van de leider bepalen en dit aan de client doorgeven, zonder de berekening van de consensus via het Raft-protocol uit te voeren. <\/p>\n
De wijziging heeft ook de noodzaak voor een apart component voor metadata-synchronisatie ge\u00eblimineerd en aparte verwerking van de Raft-status en metadata uitgesloten. Secundaire knooppunten sturen nu verzoeken naar de leidersknop alleen wanneer dat nodig is, om het adres van de leidende knop te achterhalen. De API biedt de mogelijkheid om informatie over de status van andere knooppunten in de cluster op te halen. In de opdrachtregelinterface is de opdracht «.sysdump» toegevoegd. \n Bron: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"