Lanzamiento de rqlite 6.0, un DBMS tolerante a fallas distribuido basado en SQLite

Se presenta el lanzamiento del DBMS distribuido rqlite 6.0, que utiliza SQLite como motor de almacenamiento y permite organizar el trabajo de un clúster de almacenamiento sincronizado. Una de las características de rqlite es la facilidad de instalación, implementación y mantenimiento de un almacenamiento distribuido tolerante a fallas, algo similar a etcd y Consul, pero utilizando un modelo de datos relacional en lugar de un formato clave/valor. El código del proyecto está escrito en Go y distribuido bajo la licencia MIT.

Para mantener todos los nodos en un estado sincronizado, se utiliza el algoritmo de consenso Raft. Rqlite utiliza la biblioteca SQLite original y el controlador estándar go-sqlite3, sobre el cual se inicia una capa que procesa las solicitudes de los clientes, realiza la replicación a otros nodos y monitorea el logro de un consenso sobre la elección del nodo líder.

Los cambios en la base de datos solo pueden ser realizados por el nodo seleccionado como líder, pero las conexiones con operaciones de escritura también se pueden enviar a otros nodos del clúster, que devolverán la dirección del líder para repetir la solicitud (en la próxima versión promete agregar el reenvío automático de solicitudes al líder). El énfasis principal está en la tolerancia a fallos, por lo que el DBMS escala sólo con operaciones de lectura, y las operaciones de escritura son el cuello de botella. Es posible ejecutar un clúster rqlite desde un solo nodo y esta solución se puede utilizar para proporcionar acceso a SQLite a través de HTTP sin proporcionar tolerancia a fallos.

Los datos de SQLite en cada nodo no se almacenan en un archivo, sino en la memoria. A nivel de capa, con la implementación del protocolo Raft, se mantiene un registro de todos los comandos SQLite que conducen a cambios en la base de datos. Este registro se utiliza durante la replicación (replicación a nivel de reproducción de solicitudes en otros nodos), el inicio de un nuevo nodo o la recuperación de una pérdida de conectividad. Para reducir el tamaño del registro, se utiliza el empaquetado automático, que comienza después de un número específico de cambios y conduce a la fijación de una instantánea en el disco, en relación con la cual comienza a guardarse un nuevo registro (el estado de la base de datos en la memoria). es idéntico a la instantánea + el registro de cambios acumulado).

Características de rqlite:

  • Fácil de implementar un clúster, sin necesidad de una instalación de SQLite por separado.
  • Capacidad de obtener rápidamente almacenamiento SQL replicado.
  • Listo para usar en proyectos de trabajo (grado de producción).
  • La presencia de una API HTTP(S) que le permite actualizar datos en modo por lotes y determinar el nodo principal del clúster. También proporciona una interfaz de línea de comandos y la capacidad de utilizar varias bibliotecas cliente creadas para SQLite.
  • Disponibilidad de un servicio para identificar otros nodos, permitiéndole crear clusters dinámicamente.
  • Soporte para cifrar el intercambio de datos entre nodos.
  • Capacidad para configurar el nivel de verificación de la relevancia y coherencia de los datos durante la lectura.
  • Capacidad opcional para conectar nodos en modo de solo lectura, que no participan en la determinación del consenso y se utilizan para aumentar la escalabilidad del clúster para operaciones de lectura.
  • Soporte para su propia forma de transacciones basadas en la combinación de comandos en una sola solicitud (las transacciones basadas en BEGIN, COMMIT, ROLLBACK, SAVEPOINT y RELEASE no son compatibles).
  • Soporte para la creación de copias de seguridad en caliente.

La nueva versión introduce cambios arquitectónicos significativos destinados a aumentar la confiabilidad del clúster mejorando el proceso de enrutamiento de solicitudes de lectura y escritura a los nodos correctos del clúster. Los nodos rqlite ahora pueden multiplexar múltiples conexiones lógicas entre ellos utilizando conexiones TCP establecidas entre nodos mediante el protocolo Raft. Si una solicitud requiere la autoridad del líder pero se envía a un nodo secundario, el nodo secundario puede determinar la dirección del líder y pasársela al cliente sin realizar cálculos de consenso de Raft.

El cambio también eliminó la necesidad de un componente de sincronización de metadatos separado y eliminó el manejo por separado del estado de Raft y los metadatos. Los nodos secundarios ahora envían solicitudes al nodo líder solo cuando es necesario, cuando necesitan averiguar la dirección del nodo líder. La API brinda la capacidad de obtener información sobre el estado de otros nodos en el clúster. El comando ".sysdump" se ha agregado a la interfaz de línea de comandos.

Fuente: opennet.ru

Añadir un comentario