Litestream agora permite restauração pontual rápida

 (fly.io)
6 pontos por GN⁺ 2025-05-22 | 2 comentários | Compartilhar no WhatsApp
  • Litestream faz backup com segurança de aplicações full stack baseadas em SQLite em armazenamento de objetos, e esta atualização traz a maior mudança de funcionalidade até agora
  • Com a adoção do formato de arquivo LTX e de técnicas de compactação mais eficientes que a estrutura anterior, agora é possível fazer restauração pontual de forma rápida e eficiente
  • Um novo método usando conditional write simplifica a implementação de singleton de leitura e de recursos de read replica
  • Em breve, uma camada de read replica baseada em VFS será disponibilizada, permitindo expansão fácil em diversos ambientes
  • A estrutura amplamente aprimorada permite sincronizar vários bancos de dados ao mesmo tempo, aumentando a escalabilidade

Introdução ao Litestream e sua importância

  • Litestream é uma ferramenta open source que oferece backup seguro em armazenamento de objetos para diversas aplicações full stack baseadas em SQLite
  • Ela resolve o problema de os dados ficarem presos a um único servidor por causa da natureza embarcada do SQLite, facilitando a recuperação de dados mesmo em caso de falha do servidor

A evolução do Litestream

  • O Litestream surgiu em 2020 para tornar o uso do SQLite mais simples
  • O Litestream roda como um processo separado da aplicação SQLite e substitui o processo de checkpoint do WAL, transmitindo em tempo real as alterações de dados para armazenamento de objetos como o S3
  • Mesmo que o servidor seja perdido, é possível restaurar o banco de dados de forma eficiente a partir do estado mais recente no armazenamento de objetos
  • Depois, foi desenvolvido o projeto LiteFS, que passou a oferecer read replicas e failover primário básico (Primary Failover), permitindo usar o SQLite em uma arquitetura moderna de implantação, semelhante ao Postgres
  • Tanto o LiteFS quanto o Litestream têm suas vantagens, mas o Litestream é mais amplamente usado por ser mais fácil de implantar e utilizar

Restauração pontual eficiente (Point-in-time Restore)

  • O design anterior do Litestream registrava continuamente todas as mudanças e as enviava ao S3, mas isso era ineficiente na restauração quando os dados mudavam com frequência
  • No LiteFS, foi adotada uma abordagem consciente de transações, usando o formato de arquivo LTX, que registra os intervalos de páginas alteradas em ordem
  • Vários arquivos LTX podem ser facilmente mesclados (compaction), mantendo apenas a versão mais recente, o que melhora drasticamente a velocidade e a eficiência da recuperação de dados
  • Essa estrutura é semelhante a uma árvore LSM
  • O novo Litestream também adota arquivos LTX e compactação, permitindo restauração pontual exata sem grande armazenamento redundante

CASAAS: Compare-and-Swap as a Service

  • O Litestream precisa funcionar sem que a aplicação SQLite tenha consciência do sistema de backup, e quando processos morrem por falhas, pode haver perda de alterações de dados
  • Para resolver isso, foi introduzido o conceito de generation, que identifica de forma única cada sessão de backup e seu fluxo de logs correspondente
  • No LiteFS, o Consul era usado para garantir um único líder, mas como isso exigia dependências externas, o Litestream passou a implementar um caminho único de replicação (singleton) de forma simples usando o recurso de conditional write de armazenamentos de objetos como o S3
  • Com isso, a operação pode permanecer estável e sem ambiguidades até mesmo em ambientes com nós efêmeros

Recurso leve de read replica

  • O LiteFS usa o sistema de arquivos FUSE para ter consciência de transações, mas isso traz complexidade e aumenta a barreira de adoção
  • Para aliviar isso, foi projetado o LiteVFS, um módulo de extensão de SQLite Virtual Filesystem (VFS) que permite operar em diversos ambientes sem FUSE
  • No futuro, o Litestream também adotará a mesma camada baseada em VFS para oferecer uma camada de read replica que busca e armazena em cache páginas diretamente de armazenamentos de objetos como o S3
  • Ele não será tão rápido quanto um SQLite local, mas espera-se que estratégias de cache e prefetching ofereçam desempenho satisfatório em muitos casos de uso

Open source e utilidade prática

  • O Litestream é totalmente open source, não depende do Fly.io e pode ser usado em qualquer lugar
  • Foi adicionada a capacidade de sincronizar um grande volume de bancos de dados em um único processo, permitindo fazer backup ou replicação com eficiência de centenas a milhares de bancos de dados

Crescimento contínuo junto com o SQLite

  • O SQLite é um banco de dados robusto que continua criando novos casos de uso mesmo em meio às mudanças da indústria
  • Em áreas recentes como agentes de geração de código baseados em LLM, a capacidade de rollback e ramificação de dados em tempo real está se tornando importante, e a evolução da restauração pontual do Litestream pode se tornar uma base essencial
  • No futuro, essa arquitetura aprimorada também poderá contribuir para recursos expandidos como rollback, fork e suporte a agentes automatizados
  • O novo Litestream é superior ao design anterior e reforça tanto a escalabilidade quanto a usabilidade

Leituras relacionadas

2 comentários

 
GN⁺ 2025-05-22
Comentários do Hacker News

  • Relato de alguém que já teve experiência localizando o repositório do código, dizendo que há 2 anos teve dificuldades ao usar litestream e litefs, mas que desta vez parece que a maioria dos problemas foi resolvida; agora vê como possível aplicar litestream ao banco de dados com muito mais liberdade e se preocupar menos com questões de múltiplos writers, além de esperar vantagens da camada FUSE de read replica; também apresenta, no pull request relacionado, a forma de assumir o lease (se já existir um lease, o novo processo tenta novamente a cada 1 segundo, permitindo rolling restart rápido), considerando isso uma abordagem prática

  • Sensação de que tudo o que eu queria no novo Litestream finalmente foi implementado, gerando expectativa e empolgação

  • Visão positiva sobre uma solução muito inteligente e que simplifica a implantação; em uma situação em que era preciso fazer backup de milhares de bancos SQLite, até agora a pessoa havia improvisado uma solução com fanotify e a Backup API do SQLite, e espera migrar para o Litestream se a replicação com wildcard passar a suportar muitos arquivos

  • Destaque para o fato de que, após a transição para LTX, passou a ser possível replicar /data/*.db mesmo com centenas ou milhares de bancos em um diretório; isso era antes um bloqueio decisivo, e agora há uma visão positiva de que em ambientes multitenant será possível fazer recuperação em um ponto no tempo, download de dados e migração por banco de dados de cada usuário

  • Agradecimento ao ben junto com um relato de uso real: há mais de 1 ano, em um caso interno com muitas escritas (cerca de 12GB após compressão), a pessoa usa litestream em produção e o custo mensal é praticamente insignificante (no Azure, algo na faixa de alguns centavos de real), e está ansiosa para aplicar as novas mudanças

  • Desejo de que a experiência de desenvolvimento com SQLite no Fly fique um pouco mais refinada; entre os pontos frustrantes atuais estão a falta de uma UI e CLI próprias, o que faz com que configurar o banco inicial em uma Fly Machine envolva mais etapas do que o esperado; fly console não se integra direito com SQLite e roda em outra máquina, então não consegue acessar o volume onde os dados estão; no fim, é preciso entrar diretamente naquela máquina com fly ssh console —pty, o que é inconveniente; também aponta a dificuldade de monetizar apps web baseadas em SQLite, já que a maioria é pequena e seria necessário operar muitas para ter retorno

    • Pergunta sobre a direção pessoal de escolha com a combinação Rails 8 + SQLite, querendo saber se ultimamente isso é preferido em relação ao Postgres

  • Relato de alguém que estava justamente pesquisando Litestream e encontrou o texto no momento certo; usa Sqlite em uma VPS e está considerando adotar Litestream; pergunta se é possível restaurar o banco para um ponto específico no tempo enquanto o processo do Litestream está em execução, e levanta a dúvida sobre janelas de restauração impossíveis devido ao auto-checkpointing consumir o WAL quando o processo cai (exemplo: processo parado entre 2:00 e 3:00 por falha; seria possível restaurar para 1:55 ou 3:05, mas talvez as informações entre 2:00 e 3:00 desapareçam)

    • Explicação de que o Litestream armazena segmentos de WAL por unidade de tempo específica e, por padrão, envia as mudanças do WAL a cada segundo, então é possível restaurar com granularidade de segundos para o ponto desejado (dentro do período de retenção configurado)

    • Pergunta sobre o tratamento de DST (horário de verão), querendo saber como funcionaria no caso europeu em que no dia 30 de março o relógio salta de 2:00 para 3:00

  • Relato de alguém que no passado criou um sqlite vfs chamado DonutDB baseado em dynamodb; com a adição de CAS (Content Addressable Storage) ao S3, pretendia renovar o DonutDB com suporte a S3, mas agora ficou feliz por o lightstream passar a oferecer isso e não precisar mais desenvolver por conta própria, mostrando expectativa em usar a nova ferramenta

    • Diante da menção de que o S3 ganhou CAS (Content Addressable Storage), pede material oficial ou links de referência, e quer confirmar se esse é mesmo o significado de CAS

  • Recorda que, ao fazer deploy do app, no método anterior era iniciado um novo servidor, o tráfego era desviado após o health check passar e então o servidor antigo era encerrado, mas nesse processo havia perda de alterações no banco; pergunta se essa mudança resolveu esse problema

    • Opinião de que o servidor deve ser encarado não como uma instância efêmera de servidor web, mas sob a ótica de um banco de dados de produção; ao implantar um app web com python/sqlite, a pessoa não substitui a máquina inteira, e sim atualiza apenas os pacotes e reinicia o serviço systemd; para reduzir downtime, seria possível pensar na troca com SO_REUSEPORT e similares, e nesse caso processos novo e antigo até podem usar o banco ao mesmo tempo, mas se houver alteração de esquema no DB algum downtime acaba sendo inevitável; entende que isso pode valer também para outros bancos

    • Posição de que o problema ainda não é fácil de resolver, pois continua havendo apenas um writer que pode segurar o lease; mesmo que o novo serviço suba, ele só obterá o lease quando o writer anterior cair; há ferramentas para facilitar a troca do writer, mas esperar requisições terminarem ou aceitar um breve downtime continua sendo inevitável

  • Pergunta sobre como adicionar dinamicamente novos bancos em tempo de execução para replicar inúmeros bancos por usuário com litestream (um dos casos de uso centrais na documentação); relata que hoje o arquivo de configuração é estático e não encontrou uma API em tempo real

    • A expectativa é de que esse problema acabe sendo resolvido; detecta-se que a nova lógica de descoberta de SQLite é delicada, mas não impossível, e até lá há a orientação de que a solução pode ser usada facilmente no formato de biblioteca