rqlite 7.0 er allerede blevet frigivet, og dette er nyhederne

nylig udgivelsen af ​​det distribuerede DBMS rqlite 7.0 blev annonceret, hvori denne nye version introducerer en ny node discovery integration med Consul og etcd. Brug af et af disse systemer med rqlite gør rqlites automatiske klyngedannelse meget nemmere, plus ældre Discovery-tilstand er ikke understøttet i version 7.0, men kan være i en fremtidig udgivelse.

For dem, der ikke er klar over rqlite, bør de vide det denne, der bruger SQLite som en storage-motor og tillader at organisere driften af ​​en klynge fra lagre synkroniseret med hinanden.

Af egenskaberne ved rqlite skiller det sig ud distribueret fejltolerant lagring er nem at installere, implementere og vedligeholde, noget ligner etcd og Consul , men bruger en relationel datamodel i stedet for et nøgle/værdi-format.

Rafts konsensusalgoritme bruges til at holde alle noder synkroniseret. Rqlite bruger det originale SQLite-bibliotek og go-sqlite3-driveren, derudover kører det et lag, der behandler anmodninger fra klienter, udfører replikering til andre noder og overvåger konsensus om valget af lederknudepunktet.

Databaseændringer kan kun foretages af den node, der er valgt som leder, men skriveforbindelser kan dirigeres til andre noder i klyngen, som returnerer lederens adresse for at gentage anmodningen.

Hovedvægten er på fejltolerance, så DBMS-skalering kun ved læsning og skrivning er flaskehalsen. Det er muligt at køre en rqlite-klynge fra en enkelt node, og en sådan løsning kan bruges til at give adgang til SQLite over HTTP uden at give fejltolerance.

SQLite-data på hver node er ikke lagret i en fil, men i hukommelsen. På lagniveau med Raft-protokolimplementeringen føres en log over alle SQLite-kommandoer, der fører til en databaseændring.

Denne log bruges til replikering (replikering på genafspilningsniveau til andre noder), når du starter en ny node, eller til at gendanne efter et tab af forbindelse. For at reducere størrelsen på stammen anvendes automatisk pakning, som starter efter et specificeret antal ændringer og fører til commit af et snapshot, i forbindelse med hvilken en ny record startes (databasetilstand i hukommelsen er identisk med snapshot + changelog akkumuleret).

De vigtigste nyheder i rqlite 7.0

I denne nye version, der præsenteres vi kan opdage, at understøttelse af rqlite automatisk klyngedannelse blev tilføjet ved hjælp af en ny node discovery service, der kan køre på Consuls distribuerede lager og etcd. Som sådan tillader tjenesten, at rqlite-noder kan findes automatisk: administratoren behøver kun at køre flere noder på forskellige servere ved at angive den fælles adresse på Consul- eller etcd-klyngen (f.eks. "example.com:8500") og noderne vil automatisk blive grupperet sammen. .

Lederknudepunktet opdaterer med jævne mellemrum sine adresseoplysninger i Consul eller etcd-lageret, hvilket giver dig mulighed for at ændre lederen i fremtiden uden at omkonfigurere de resterende knudepunkter og tilføje nye knudepunkter, selv efter at lederen er ændret.

En anden ændring, der skiller sig ud, er den afbrudt support til den gamle Discovery-tilstandstjeneste drevet af AWS Lambda.

Udover det i CLI-grænsefladen er det tilladt at angive flere værter på én gang: hvis den første node ikke er tilgængelig, vil følgende værter blive kontaktet.

Det bemærkes også, at omdesignet kode til at parse rqlited kommandolinjeargumenter og at den forældede protobuf-pakke er blevet forældet.

Mens BoltDB-lageret brugt i Raft-protokolimplementeringen er blevet afløst af bbolt, en forgrening af etcd-projektet.

Endelig hvis du er interesseret i at vide mere om det, kan du kontrollere detaljerne i følgende link.