È stato rilasciato rqlite 6.0, un sistema di gestione di database distribuiti che utilizza SQLite come motore di archiviazione e consente di organizzare il lavoro di un cluster di archiviazione sincronizzati tra loro. Tra le caratteristiche di rqlite si segnala la semplicità di installazione, distribuzione e manutenzione di un'archiviazione distribuita e resiliente, simile a etcd e Consul, ma che utilizza un modello relazionale per la gestione dei dati anziché il formato chiave/valore. Il codice del progetto è scritto in Go e distribuito con licenza MIT.
Per mantenere tutti i nodi in uno stato sincronizzato viene utilizzato l'algoritmo di consenso Raft. Rqlite usa la libreria SQLite originale e il driver go-sqlite3, sopra i quali viene eseguita un'interfaccia che gestisce le richieste dei client, esegue la replica su altri nodi e monitora il raggiungimento del consenso per la scelta del nodo leader.
Le modifiche al database possono essere apportate solo dal nodo scelto come leader, ma le connessioni per operazioni di scrittura possono essere inviate anche ad altri nodi del cluster, che restituiranno l'indirizzo del leader per ripetere la richiesta (nella prossima versione promettono di aggiungere un'instradamento automatico verso il leader). L'accento è posto sulla resilienza, per cui il DBMS è scalabile solo per le operazioni di lettura, mentre le operazioni di scrittura rappresentano un collo di bottiglia. È possibile avviare un cluster rqlite da un unico nodo e questa soluzione può essere utilizzata per organizzare l'accesso a SQLite via HTTP senza fornire resilienza.
I dati SQLite su ogni nodo non sono memorizzati in un file, ma in memoria. A livello del layer che implementa il protocollo Raft viene mantenuto un log di tutti i comandi SQLite che comportano modifiche al database. Questo log viene utilizzato durante la replica (replica a livello di riproduzione delle richieste su altri nodi), all'avvio di un nuovo nodo o al ripristino dopo una perdita di connettività. Per ridurre la dimensione del log viene applicata una compressione automatica che viene avviata dopo un numero prestabilito di modifiche e porta alla registrazione su disco di uno snapshot, rispetto al quale inizia a essere mantenuto un nuovo log (lo stato del database in memoria è identico allo snapshot più il log delle modifiche accumulate).
Caratteristiche di rqlite:
- Semplicità nella distribuzione del cluster, senza la necessità di un'installazione separata di SQLite.
- La possibilità di ottenere rapidamente uno spazio di archiviazione SQL replicato.
- Pronto per l'uso in progetti di lavoro (di livello produttivo).
- Disponibilità di un'API HTTP(S) che consente di aggiornare i dati in modalità batch e di determinare il nodo leader del cluster. Viene fornito anche un'interfaccia a riga di comando e la possibilità di utilizzare diverse librerie client create per SQLite.
- Disponibilità di un servizio per la determinazione 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 verifica della validità e coerenza dei dati durante la lettura.
- Opzionale possibilità di collegare nodi in modalità 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 una forma proprietaria di transazioni basate sulla fusione di comandi in un'unica richiesta (non sono supportate transazioni basate su BEGIN, COMMIT, ROLLBACK, SAVEPOINT e RELEASE).
- Supporto per la creazione di backup a caldo.
Nella nuova versione sono state apportate significative modifiche architettoniche volte a migliorare 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 connessioni TCP stabilite tra i nodi tramite il protocollo Raft. Se una richiesta richiede privilegi dal nodo leader ma viene inviata a un nodo secondario, il nodo secondario può determinare l'indirizzo del leader e comunicarlo al client, senza effettuare il calcolo del consenso tramite il protocollo Raft.
La modifica ha anche permesso di eliminare un componente separato per la sincronizzazione dei metadati e di escludere il trattamento separato dello stato di Raft e dei metadati. I nodi secondari ora instradano le richieste solo quando necessario, quando è necessario conoscere l'indirizzo del nodo leader. Nell'API è fornita la possibilità di ottenere informazioni sullo stato degli altri nodi nel cluster. È stato aggiunto un comando '.sysdump' all'interfaccia della riga di comando.
Fonte: opennet.ru
