Utgåvan av rqlite 6.0, en distribuerad felresistent DBMS baserad på SQLite

Utgåvan av den distribuerade databashanteraren rqlite 6.0 har presenterats, som använder SQLite som lagringsmotor och möjliggör att organisera en kluster av synkroniserade lagringssystem. Bland rqlites egenskaper märks enkel installation, distribution och underhåll av ett distribuerat och felresistent lagringssystem, liknande etcd och Consul, men som använder en relationsmodell för databehandling istället för nyckel/värde-formatet. Projektets kod är skriven i Go och distribueras under MIT-licensen.

För att hålla alla noder i synkroniserat tillstånd används Raft-konsensusalgoritmen. Rqlite använder den ursprungliga SQLite-biblioteket och den inbyggda drivrutinen go-sqlite3, ovanpå vilket en mellanlager körs som hanterar klientförfrågningar, utför replikering till andra noder och övervakar uppnåendet av konsensus för val av ledande nod.

Ändringar i databasen kan endast göras av den nod som valts som ledande, men förbindelser med skrivoperationer kan riktas mot andra noder i klustret, som kommer att returnera adressen till ledaren för att upprepa förfrågan (i nästa version lovas automatisk vidarebefordran till ledaren). Huvudfokus ligger på felresistens, vilket innebär att databashanteraren bara kan skalas upp för läsoperationer, medan skrivoperationer är ett flaskhals. Det är möjligt att starta en rqlite-kluster från en enda nod, och denna lösning kan användas för att organisera åtkomst till SQLite över HTTP utan att erbjuda felresistens.

SQLite-data på varje nod lagras inte i en fil utan i minnet. På nivån för Raft-protokollets implementering finns en logg över alla SQLite-kommando som leder till förändringar i databasen. Denna logg används vid replikering (replikering på nivå med att återge förfrågningar på andra noder), start av en ny nod eller återställning efter förlust av anslutning. För att minska loggens storlek tillämpas automatisk paketering, som startar efter ett angivet antal förändringar och leder till att ett snapshot skrivs till disk, vilket det nya logget baseras på (databasens tillstånd i minnet är identiskt med snapshotet + den ackumulerade förändringsloggen).

Features of rqlite:

• Ease of deploying the cluster without needing a separate SQLite installation.
• Möjlighet att snabbt få ett replikerat SQL-lager.
• Klar för användning i arbetsprojekt (Production-grade).
• Tillgång till ett HTTP(S) API som möjliggör uppdatering av data i batch och definiering av ledande nod i klustret. En kommandoradsgränssnitt och möjlighet att använda olika klientbibliotek skapade för SQLite tillhandahålls också.
• Tillgång till en tjänst för att identifiera andra noder, vilket möjliggör dynamisk skapande av kluster.
• Stöd för kryptering av datakommunikation mellan noder.
• Möjlighet att konfigurera nivån av giltighets- och konsistenskontroll vid läsning.
• Valfri möjlighet att koppla noder i skrivskyddat läge, som inte deltar i konsensusbestämningen och används för att öka klustrets skalbarhet vid läsoperationer.
• Stöd för egendefinierade transaktionsformer baserade på sammanslagning av kommandon i en förfrågan (transaktioner baserade på BEGIN, COMMIT, ROLLBACK, SAVEPOINT och RELEASE stöds inte).
• Stöd för skapande av heta säkerhetskopior.

I den nya utgåvan har betydande arkitektoniska förändringar gjorts för att öka klustrets tillförlitlighet genom att förbättra processen för att dirigera läs- och skrivförfrågningar till korrekta noder i klustret. Rqlite-noder kan nu multiplexera flera logiska anslutningar mellan varandra, med hjälp av TCP-anslutningar som upprättats mellan noderna via Raft-protokollet. Om en begäran kräver behörigheter från den ledande noden men skickas till en sekundär nod, kan den sekundära noden bestämma ledarens adress och vidarebefordra den till klienten utan att utföra konsensusberäkningen enligt Raft-protokollet.

Ändringen har också möjliggjort att man kan eliminera en separat komponent för synkronisering av metadata och utesluta separat behandling av Raft-tillstånd och metadata. Sekundära noder riktar nu förfrågningar till ledarnoden endast vid behov, när det är nödvändigt att ta reda på adressen till den ledande noden. API:et erbjuder möjlighet att hämta information om tillståndet för andra noder i klustret. Ett nytt kommando " .sysdump " har lagts till i kommandoradsgränssnittet.

Källa: opennet.ru