Lanzamento de rqlite 6.0, un DBMS distribuído tolerante a fallos baseado en SQLite

Presentouse a versión do DBMS distribuído rqlite 6.0, que utiliza SQLite como motor de almacenamento e permite organizar o traballo dun clúster a partir de almacenamentos sincronizados entre si. Unha das características de rqlite é a facilidade de instalación, implantación e mantemento dun almacenamento distribuído tolerante a fallos, algo semellante a etcd e Consul, pero usando un modelo de datos relacionais en lugar dun formato de clave/valor. O código do proxecto está escrito en Go e distribúese baixo a licenza MIT.

Para manter todos os nodos nun estado sincronizado, utilízase o algoritmo de consenso Raft. Rqlite usa a biblioteca SQLite orixinal e o controlador estándar go-sqlite3, enriba do cal se inicia unha capa que procesa as solicitudes dos clientes, realiza a replicación a outros nodos e supervisa a consecución do consenso sobre a elección dun nodo líder.

Os cambios na base de datos só os pode facer o nodo seleccionado como líder, pero as conexións con operacións de escritura tamén se poden enviar a outros nodos do clúster, que devolverán o enderezo do líder para repetir a solicitude (na seguinte versión promesa de engadir o reenvío automático de solicitudes ao líder). A principal énfase está na tolerancia a fallos, polo que o DBMS só escala con operacións de lectura e as operacións de escritura son o pescozo de botella. É posible executar un clúster rqlite desde un só nodo e esta solución pódese usar para proporcionar acceso a SQLite a través de HTTP sen proporcionar tolerancia a fallos.

Os datos de SQLite en cada nodo non se almacenan nun ficheiro, senón na memoria. A nivel de capa coa implementación do protocolo Raft, gárdase un rexistro de todos os comandos de SQLite que levan a cambios na base de datos. Este rexistro utilízase durante a replicación (replicación a nivel de reprodución de solicitudes noutros nodos), o inicio dun novo nodo ou a recuperación dunha perda de conectividade. Para reducir o tamaño do rexistro, utilízase o empaquetado automático, que se inicia despois dun número determinado de cambios e leva a que se arranxe unha instantánea no disco, en relación coa que se comeza a gardar un novo rexistro (o estado da base de datos na memoria). é idéntico á instantánea + o rexistro de cambios acumulado).

Características de rqlite:

  • Fácil de implantar un clúster, sen necesidade dunha instalación separada de SQLite.
  • Capacidade de obter rapidamente almacenamento SQL replicado.
  • Listo para usar en proxectos de traballo (grado de produción).
  • A presenza dunha API HTTP(S) que lle permite actualizar os datos en modo por lotes e determinar o nodo principal do clúster. Tamén ofrece unha interface de liña de comandos e a capacidade de usar varias bibliotecas de clientes creadas para SQLite.
  • Dispoñibilidade dun servizo para identificar outros nodos, que permite crear clusters de forma dinámica.
  • Soporte para cifrar o intercambio de datos entre nodos.
  • Capacidade de configurar o nivel de comprobación da relevancia e coherencia dos datos ao ler.
  • Capacidade opcional para conectar os nós en modo de só lectura, que non participan na determinación do consenso e úsanse para aumentar a escalabilidade do clúster para as operacións de lectura.
  • Compatibilidade coa túa propia forma de transaccións baseada na combinación de comandos nunha única solicitude (non se admiten transaccións baseadas en BEGIN, COMMIT, ROLLBACK, SAVEPOINT e RELEASE).
  • Soporte para a creación de copias de seguridade en quente.

A nova versión introduce cambios arquitectónicos significativos destinados a aumentar a fiabilidade do clúster mellorando o proceso de enrutamento das solicitudes de lectura e escritura aos nodos do clúster correctos. Os nodos rqlite agora poden multiplexar varias conexións lóxicas entre si utilizando conexións TCP establecidas entre nós polo protocolo Raft. Se unha solicitude require a autoridade do líder pero se envía a un nodo secundario, o nodo secundario pode determinar o enderezo do líder e transmitilo ao cliente sen realizar cálculos de consenso de Raft.

O cambio tamén eliminou a necesidade dun compoñente de sincronización de metadatos separado e eliminou o manexo separado do estado e dos metadatos de Raft. Os nodos secundarios agora envían solicitudes ao nodo líder só cando é necesario, cando precisan descubrir o enderezo do nodo líder. A API ofrece a posibilidade de obter información sobre o estado doutros nodos do clúster. O comando ".sysdump" engadiuse á interface da liña de comandos.

Fonte: opennet.ru

Engadir un comentario