Foi apresentado o lançamento do SGBD distribuído rqlite 6.0, que utiliza SQLite como mecanismo de armazenamento e permite organizar o trabalho de um cluster a partir de armazenamentos sincronizados entre si. Uma das características do rqlite é a facilidade de instalação, implantação e manutenção de um armazenamento distribuído tolerante a falhas, um pouco semelhante ao etcd e ao Consul, mas usando um modelo de dados relacional em vez de um formato chave/valor. O código do projeto é escrito em Go e distribuído sob a licença do MIT.
Para manter todos os nós em um estado sincronizado, o algoritmo de consenso Raft é usado. Rqlite usa a biblioteca SQLite original e o driver padrão go-sqlite3, sobre o qual é lançada uma camada que processa as solicitações do cliente, realiza replicação para outros nós e monitora a obtenção de consenso na escolha de um nó líder.
Mudanças no banco de dados só podem ser feitas pelo nó selecionado como líder, mas conexões com operações de gravação também podem ser enviadas para outros nós do cluster, que retornarão o endereço do líder para repetir a solicitação (na próxima versão eles promessa de adicionar encaminhamento automático de solicitações ao líder). A ênfase principal está na tolerância a falhas, de modo que o SGBD é dimensionado apenas com operações de leitura, e as operações de gravação são o gargalo. É possível executar um cluster rqlite a partir de um único nó e esta solução pode ser usada para fornecer acesso ao SQLite por HTTP sem fornecer tolerância a falhas.
Os dados SQLite em cada nó não são armazenados em um arquivo, mas na memória. No nível da camada com a implementação do protocolo Raft, é mantido um log de todos os comandos SQLite que levam a alterações no banco de dados. Este log é usado durante a replicação (replicação no nível de reprodução de solicitações em outros nós), iniciando um novo nó ou recuperando-se de uma perda de conectividade. Para reduzir o tamanho do log, é utilizado o empacotamento automático, que começa após um determinado número de alterações e leva à fixação de um snapshot no disco, em relação ao qual um novo log começa a ser mantido (o estado do banco de dados na memória é idêntico ao instantâneo + o log de alterações acumulado).
Recursos do rqlite:
- Fácil de implantar um cluster, sem a necessidade de uma instalação separada do SQLite.
- Capacidade de obter rapidamente armazenamento SQL replicado.
- Pronto para uso em projetos de trabalho (grau de produção).
- A presença de uma API HTTP(S) que permite atualizar dados em modo batch e determinar o nó líder do cluster. Ele também fornece uma interface de linha de comando e a capacidade de usar várias bibliotecas cliente construídas para SQLite.
- Disponibilização de um serviço de identificação de outros nós, permitindo a criação de clusters de forma dinâmica.
- Suporte para criptografia de troca de dados entre nós.
- Capacidade de configurar o nível de verificação da relevância e consistência dos dados durante a leitura.
- Capacidade opcional de conectar nós em modo somente leitura, que não participam na determinação do consenso e são usados para aumentar a escalabilidade do cluster para operações de leitura.
- Suporte para sua própria forma de transação baseada na combinação de comandos em uma solicitação (transações baseadas em BEGIN, COMMIT, ROLLBACK, SAVEPOINT e RELEASE não são suportadas).
- Suporte para criação de backups dinâmicos.
A nova versão introduz alterações arquitetônicas significativas destinadas a aumentar a confiabilidade do cluster, melhorando o processo de roteamento de solicitações de leitura e gravação para os nós corretos do cluster. Os nós rqlite agora podem multiplexar múltiplas conexões lógicas entre si usando conexões TCP estabelecidas entre nós pelo protocolo Raft. Se uma solicitação exigir autoridade do líder, mas for enviada a um nó secundário, o nó secundário poderá determinar o endereço do líder e repassá-lo ao cliente sem realizar cálculos de consenso do Raft.
A mudança também eliminou a necessidade de um componente separado de sincronização de metadados e eliminou o tratamento separado do estado e dos metadados do Raft. Os nós secundários agora enviam solicitações ao nó líder somente quando necessário, quando precisam descobrir o endereço do nó líder. A API fornece a capacidade de obter informações sobre o estado de outros nós do cluster. O comando “.sysdump” foi adicionado à interface da linha de comando.
Fonte: opennet.ru