Viene presentata la release del DBMS distribuito rqlite 6.0, che utilizza SQLite come motore di storage e consente di organizzare il lavoro di un cluster di storage sincronizzati. Una delle caratteristiche di rqlite è la facilità di installazione, distribuzione e manutenzione di uno storage distribuito con tolleranza agli errori, in qualche modo simile a etcd e Consul, ma utilizzando un modello di dati relazionale invece di un formato chiave/valore. Il codice del progetto è scritto in Go e distribuito sotto la licenza MIT.
Per mantenere tutti i nodi in uno stato sincronizzato, viene utilizzato l'algoritmo di consenso Raft. Rqlite utilizza la libreria SQLite originale e il driver standard go-sqlite3, sopra il quale viene lanciato un livello che elabora le richieste del client, esegue la replica su altri nodi e monitora il raggiungimento del consenso sulla scelta del nodo principale.
Le modifiche al database possono essere effettuate solo dal nodo selezionato come capofila, ma le connessioni con operazioni di scrittura possono essere inviate anche ad altri nodi del cluster, i quali restituiranno l'indirizzo del capofila per ripetere la richiesta (nella versione successiva promessa di aggiungere l'inoltro automatico delle richieste al leader). L'enfasi principale è sulla tolleranza agli errori, quindi il DBMS scala solo con le operazioni di lettura e le operazioni di scrittura rappresentano il collo di bottiglia. È possibile eseguire un cluster rqlite da un singolo nodo e questa soluzione può essere utilizzata per fornire accesso a SQLite su HTTP senza fornire tolleranza agli errori.
I dati SQLite su ciascun nodo non vengono archiviati in un file, ma in memoria. A livello di livello con l'implementazione del protocollo Raft, viene mantenuto un registro di tutti i comandi SQLite che portano a modifiche nel database. Questo registro viene utilizzato durante la replica (replica a livello di riproduzione delle richieste su altri nodi), l'avvio di un nuovo nodo o il ripristino da una perdita di connettività. Per ridurre la dimensione del log viene utilizzato il packaging automatico, che inizia dopo un determinato numero di modifiche e porta al fissaggio di uno snapshot su disco, in relazione al quale inizia a essere mantenuto un nuovo log (lo stato del database in memoria è identico all'istantanea + al registro delle modifiche accumulato).
Caratteristiche di rqlite:
- Facile distribuzione di un cluster, senza la necessità di un'installazione SQLite separata.
- Possibilità di ottenere rapidamente spazio di archiviazione SQL replicato.
- Pronto per l'uso in progetti di lavoro (grado di produzione).
- La presenza di un'API HTTP(S) che consente di aggiornare i dati in modalità batch e determinare il nodo principale del cluster. Fornisce inoltre un'interfaccia a riga di comando e la possibilità di utilizzare varie librerie client create per SQLite.
- Disponibilità di un servizio per l'identificazione di altri nodi, che consente di creare cluster in modo dinamico.
- Supporto per la crittografia dello scambio di dati tra i nodi.
- Possibilità di configurare il livello di controllo della pertinenza e della coerenza dei dati durante la lettura.
- Possibilità facoltativa di connettere nodi in modalità di sola lettura, che non partecipano alla determinazione del consenso e vengono utilizzati per aumentare la scalabilità del cluster per le operazioni di lettura.
- Supporto per la tua forma di transazioni basata sulla combinazione di comandi in un'unica richiesta (le transazioni basate su BEGIN, COMMIT, ROLLBACK, SAVEPOINT e RELEASE non sono supportate).
- Supporto per la creazione di backup a caldo.
La nuova versione introduce modifiche architetturali significative volte ad aumentare l'affidabilità del cluster migliorando il processo di instradamento delle richieste di lettura e scrittura ai nodi corretti del cluster. I nodi rqlite ora possono multiplexare più connessioni logiche tra loro utilizzando le connessioni TCP stabilite tra i nodi dal protocollo Raft. Se una richiesta richiede l'autorità del leader ma viene inviata a un nodo secondario, il nodo secondario può determinare l'indirizzo del leader e trasmetterlo al client senza eseguire calcoli di consenso Raft.
La modifica ha inoltre eliminato la necessità di un componente di sincronizzazione dei metadati separato ed ha eliminato la gestione separata dello stato e dei metadati di Raft. I nodi secondari ora inviano richieste al nodo leader solo quando necessario, quando hanno bisogno di scoprire l'indirizzo del nodo leader. L'API offre la possibilità di ottenere informazioni sullo stato di altri nodi nel cluster. Il comando ".sysdump" è stato aggiunto all'interfaccia della riga di comando.
Fonte: opennet.ru