{"id":100516,"date":"2021-06-14T16:22:58","date_gmt":"2021-06-14T14:22:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite"},"modified":"2021-06-14T16:22:58","modified_gmt":"2021-06-14T14:22:58","slug":"vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/vypusk-rqlite-6-0-raspredelyonnoj-otkazoustojchivoj-subd-na-osnove-sqlite","title":{"rendered":"Rilascio di rqlite 6.0, un DBMS distribuito e fault-tolerant basato su SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\u00c8 stato rilasciato rqlite 6.0, un database distribuito che utilizza SQLite come motore di archiviazione e consente di organizzare un cluster di archiviazione sincronizzati tra loro. Tra le caratteristiche di rqlite spiccano la facilit\u00e0 d'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 invece del formato chiave\/valore. Il codice del progetto \u00e8 scritto in Go e distribuito con licenza MIT. <\/p>\n
Per mantenere tutti i nodi in uno stato sincronizzato, viene utilizzato l'algoritmo di consenso Raft. Rqlite utilizza la libreria originale SQLite e il driver go-sqlite3 standard, su cui viene eseguita un'interfaccia che gestisce le richieste dei clienti, esegue la replica su altri nodi e monitora il conseguimento del consenso per la selezione del nodo leader. <\/p>\n
Le modifiche nel database possono essere apportate solo dal nodo designato come leader, ma le connessioni con le operazioni di scrittura possono essere indirizzate anche ad altri nodi del cluster, i quali restituiranno l'indirizzo del leader per ripetere la richiesta (nella prossima versione si promette di aggiungere l'inoltro automatico della richiesta al leader). L'accento \u00e8 posto sulla resilienza, quindi il database pu\u00f2 scalare solo per le operazioni di lettura, mentre le operazioni di scrittura rappresentano un collo di bottiglia. \u00c8 possibile avviare un cluster rqlite da un solo nodo e questa soluzione pu\u00f2 essere utilizzata per fornire accesso a SQLite tramite HTTP senza offrire resilienza. <\/p>\n
I dati di SQLite su ogni nodo non sono memorizzati in un file, ma in memoria. A livello del layer con l'implementazione del protocollo Raft viene mantenuto un log di tutti i comandi SQLite che provocano modifiche al database. Questo log viene utilizzato durante la replica (replica a livello di riproduzione delle richieste su altri nodi), per l'avvio di un nuovo nodo o per il recupero dopo una perdita di connessione. Per ridurre la dimensione del log viene utilizzata una compressione automatica, che viene attivata dopo un numero prestabilito di modifiche e porta alla registrazione su disco di uno snapshot, rispetto al quale inizia un nuovo log (lo stato del database in memoria \u00e8 identico allo snapshot + il log delle modifiche accumulate). <\/p>\n
Caratteristiche di rqlite: <\/p>\n
\n
Semplicit\u00e0 nel dispiegamento di un cluster, senza necessit\u00e0 di installare SQLite separatamente.\n
Possibilit\u00e0 di ottenere rapidamente uno storage SQL replicato.\n
Pronto per l'uso in progetti lavorativi (Production-grade).\n
Disponibilit\u00e0 di un'API HTTP(S) che consente di aggiornare i dati in modalit\u00e0 batch e di determinare il nodo leader del cluster. Viene fornita anche un'interfaccia a riga di comando e la possibilit\u00e0 di utilizzare varie librerie client create per SQLite.\n
Disponibilit\u00e0 di un servizio per l'individuazione di altri nodi, che consente di creare cluster dinamicamente.\n
Supporto per la crittografia della comunicazione dei dati tra i nodi.\n
Possibilit\u00e0 di configurare il livello di verifica della validit\u00e0 e coerenza dei dati durante la lettura.\n
Opzione per collegare nodi in modalit\u00e0 di sola lettura, che non partecipano alla definizione del consenso e sono utilizzati per aumentare la scalabilit\u00e0 del cluster per le operazioni di lettura.\n
Supporto per una forma personalizzata di transazioni basata sulla combinazione di comandi in un'unica richiesta (non sono supportate transazioni basate su BEGIN, COMMIT, ROLLBACK, SAVEPOINT e RELEASE).\n
Supporto per la creazione di backup a caldo. <\/ul>\n
Il nuovo rilascio presenta significativi cambiamenti architettonici finalizzati a migliorare l'affidabilit\u00e0 del cluster tramite il miglioramento del processo di instradamento delle richieste di lettura e scrittura ai nodi corretti del cluster. I nodi rqlite ora possono multiplexare tra loro pi\u00f9 connessioni logiche utilizzando connessioni TCP stabilite tra i nodi tramite il protocollo Raft. Se una richiesta richiede le autorizzazioni del nodo leader, ma viene inviata a un nodo secondario, il nodo secondario pu\u00f2 determinare l'indirizzo del leader e comunicarlo al cliente, senza eseguire il calcolo del consenso secondo il protocollo Raft. <\/p>\n
La modifica ha anche permesso di eliminare un componente separato per la sincronizzazione dei metadati e di escludere una gestione separata dello stato di Raft e dei metadati. Ora, i nodi secondari indirizzano le richieste al nodo leader soltanto quando necessario, per scoprire l'indirizzo del nodo leader. Nell'API \u00e8 stata fornita la possibilit\u00e0 di ottenere informazioni sullo stato di altri nodi nel cluster. \u00c8 stato aggiunto il comando «.sysdump» nell'interfaccia della riga di comando. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"