Die vrystelling van die verspreide DBMS rqlite 6.0 word aangebied, wat SQLite as 'n bergingsenjin gebruik en jou toelaat om die werk van 'n groep gesinchroniseerde bergings te organiseer. Een van die kenmerke van rqlite is die gemak van installasie, ontplooiing en instandhouding van 'n verspreide foutverdraagsame berging, ietwat soortgelyk aan etcd en Consul, maar met behulp van 'n relasionele datamodel in plaas van 'n sleutel/waarde-formaat. Die projekkode is in Go geskryf en onder die MIT-lisensie versprei.
Om alle nodusse in 'n gesinchroniseerde toestand te hou, word die Raft-konsensusalgoritme gebruik. Rqlite gebruik die oorspronklike SQLite-biblioteek en die standaard go-sqlite3-bestuurder, boonop word 'n laag geloods wat kliëntversoeke verwerk, replikasie na ander nodusse uitvoer en die bereiking van konsensus oor die keuse van 'n leidende nodus monitor.
Veranderinge aan die databasis kan slegs gemaak word deur die nodus wat as die leier gekies is, maar verbindings met skryfbewerkings kan ook na ander nodusse in die groep gestuur word, wat die leier se adres sal terugstuur om die versoek te herhaal (in die volgende weergawe belowe om outomatiese aanstuur van versoeke aan die leier by te voeg). Die hoofklem is op fouttoleransie, so die DBMS skaal slegs met leesbewerkings, en skryfbewerkings is die bottelnek. Dit is moontlik om 'n rqlite-kluster vanaf 'n enkele nodus te laat loop en hierdie oplossing kan gebruik word om toegang tot SQLite oor HTTP te verskaf sonder om fouttoleransie te verskaf.
Die SQLite-data op elke nodus word nie in 'n lêer gestoor nie, maar in die geheue. Op die laagvlak met die implementering van die Raft-protokol word 'n log van alle SQLite-opdragte gehou wat tot veranderinge in die databasis lei. Hierdie log word gebruik tydens replikasie (replikasie op die vlak van die replikasie van versoeke op ander nodusse), die begin van 'n nuwe nodus, of herstel van 'n verlies aan konnektiwiteit. Om die grootte van die logboek te verminder, word outomatiese verpakking gebruik, wat begin na 'n gespesifiseerde aantal veranderinge en lei daartoe dat 'n momentopname op skyf reggemaak word, in verhouding waarmee 'n nuwe logboek begin gehou word (die toestand van die databasis in die geheue is identies aan die momentopname + die opgehoopte veranderingslogboek).
Kenmerke van rqlite:
- Maklik om 'n cluster te ontplooi, sonder die behoefte aan 'n aparte SQLite-installasie.
- Vermoë om vinnig gerepliseerde SQL-berging te bekom.
- Gereed vir gebruik in werkende projekte (Produksie-graad).
- Die teenwoordigheid van 'n HTTP(S) API wat jou toelaat om data in bondelmodus op te dateer en die voorste nodus van die groepie te bepaal. Dit bied ook 'n opdragreël-koppelvlak en die vermoë om verskeie kliëntbiblioteke wat vir SQLite gebou is, te gebruik.
- Beskikbaarheid van 'n diens vir die identifisering van ander nodusse, wat jou toelaat om groepe dinamies te skep.
- Ondersteuning vir die enkripteer van data-uitruiling tussen nodusse.
- Vermoë om die vlak van kontrolering van die relevansie en konsekwentheid van data tydens lees op te stel.
- Opsionele vermoë om nodusse in leesalleenmodus te verbind, wat nie deelneem aan die bepaling van konsensus nie en wat gebruik word om die skaalbaarheid van die groepering vir leesbewerkings te verhoog.
- Ondersteuning vir jou eie vorm van transaksies gebaseer op die kombinasie van opdragte in een versoek (transaksies gebaseer op BEGIN, COMMIT, ROLLBACK, SAVEPOINT en RELEASE word nie ondersteun nie).
- Ondersteuning vir die skep van warm rugsteun.
Die nuwe vrystelling stel beduidende argitektoniese veranderinge bekend wat daarop gemik is om groepbetroubaarheid te verhoog deur die proses van roetering van lees- en skryfversoeke na die korrekte groepnodusse te verbeter. rqlite-nodusse kan nou veelvuldige logiese verbindings onder mekaar vermenigvuldig met behulp van TCP-verbindings wat tussen nodusse gevestig is deur die Raft-protokol. As 'n versoek leiergesag vereis, maar na 'n sekondêre nodus gestuur word, kan die sekondêre nodus die leier se adres bepaal en dit aan die kliënt deurgee sonder om Raft-konsensusberekeninge uit te voer.
Die verandering het ook die behoefte aan 'n aparte metadata-sinchronisasiekomponent uitgeskakel en afsonderlike hantering van Raft-toestand en metadata uitgeskakel. Sekondêre nodusse stuur nou slegs versoeke na die leier node wanneer dit nodig is, wanneer hulle die adres van die leier node moet uitvind. Die API bied die vermoë om inligting te bekom oor die toestand van ander nodusse in die groepering. Die ".sysdump"-opdrag is by die opdragreël-koppelvlak gevoeg.
Bron: opennet.ru