Litestream v0.5.0
(fly.io)- Litestream v0.5.0 é uma atualização que melhora significativamente a resiliência de aplicações baseadas em SQLite
- Introduz o novo formato de arquivo LTX, com suporte a recuperação pontual eficiente (PITR) e compressão de dados
- Remove o conceito de geração (generation) entre várias instâncias do Litestream, simplificando o gerenciamento e a operação
- Com suporte a JetStream e a migração para um driver Go moderno de SQLite, o desenvolvimento e a integração ficam mais convenientes
- No futuro, estão previstas adições de recursos ainda mais poderosos, como réplicas de leitura baseadas em VFS
Visão geral e principais atualizações
- Litestream é uma ferramenta de backup e recuperação para aplicações SQLite, de código aberto e com a característica de poder rodar em qualquer lugar
- A recuperação de falhas de servidor é simples, garantindo segurança para a construção de aplicações full stack baseadas em SQLite
- A versão mais recente (v0.5.0) traz melhorias de velocidade e suporte a recuperação pontual (Point-In-Time Recovery, PITR)
Evolução do LiteFS e do Litestream
- Os principais projetos relacionados a SQLite desenvolvidos por Ben Johnson, da Fly.io, são o Litestream e o LiteFS
- O LiteFS busca replicação ao vivo no nível de transações internas do banco de dados usando o sistema de arquivos FUSE
- Porém, a demanda do mercado se concentrou no Litestream, que é mais simples de operar, o que levou ao reaproveitamento no Litestream das lições técnicas obtidas com o LiteFS
Introdução do formato de arquivo LTX
-
Para resolver as limitações e ineficiências do antigo método de backup por páginas do SQLite, foi introduzido o LTX (formato baseado em transações)
-
O LTX oferece gerenciamento de intervalos de páginas conforme a ordem das transações e compactação de páginas duplicadas (compaction)
- Exemplo: é possível aplicar vários arquivos LTX do mais recente para o mais antigo, refletindo apenas a versão mais nova das páginas duplicadas para restaurar rapidamente o estado final do banco de dados
- Por meio de uma estrutura hierárquica de arquivos, os arquivos LTX são consolidados em intervalos de 30 segundos, 5 minutos e 1 hora, reduzindo drasticamente a quantidade de arquivos necessária para a restauração
-
A velocidade de recuperação de dados fica limitada apenas pela taxa de I/O
Remoção do conceito de geração (generation)
- O Litestream pode ser executado e falhar como um processo Unix comum, e quando sua operação é interrompida, podem surgir inconsistências na sincronização de dados
- Antes, para evitar conflitos entre várias instâncias, foi introduzido um método de gerenciamento chamado geração (generation), mas
- Com a migração para LTX, a recuperação baseada em IDs de transação passou a ser possível, tornando desnecessário o gerenciamento complexo de gerações
Upgrade para o Litestream v0.5.0
- Como o formato de arquivo mudou bastante, não é possível fazer recuperação direta a partir dos segmentos WAL da v0.3.x
- O upgrade é simples: executar a nova versão → gerar novos arquivos LTX, enquanto os arquivos WAL antigos também são preservados como estão
- A compatibilidade com o arquivo de configuração também foi mantida
- Principal mudança: agora é permitido apenas um único destino de replicação por banco de dados, uma decisão tomada para facilitar o desenvolvimento e evitar conflitos de replicação
- Os comandos continuam os mesmos, mas o método de referência foi alterado para ser baseado em IDs de transação (TXID)
Outras melhorias
- A compressão por página e a adição de índice na biblioteca do formato de arquivo LTX permitem acesso seletivo a páginas dentro de arquivos grandes e expansão de funcionalidades
- Isso também viabiliza a implementação futura de recursos como consultas de dados em um ponto específico no tempo
- Com a remoção da dependência de CGO e a troca do driver SQLite em Go para o modernc.org/sqlite, surgem vantagens para builds automáticos e ambientes de cross-compilation
- Inclui suporte ao tipo de réplica JetStream, atualização dos clientes de S3/Google Storage/Azure Blob Storage e suporte à nova versão da API do S3
Planos futuros
- Está em andamento o desenvolvimento do recurso Litestream VFS para ambientes de réplica de leitura (target)
- Com esse recurso, será possível ler imediatamente do S3 apenas as páginas necessárias e gerar réplicas rapidamente
- Um protótipo já existe e está prestes a ser divulgado
1 comentários
Opiniões no Hacker News
A experiência de desenvolvedor ao implantar apps SQLite na Fly.io deixa um pouco a desejar; tentei por horas rodar um app Rails em produção, mas esbarrei em vários problemas com inicialização do banco de dados, migrações, permissões de escrita etc. A causa raiz era o eager loading de uma gem que eu mesmo criei, mas havia várias camadas de runners por cima, o que dificultou o diagnóstico. Gostaria que investissem mais em DX, embora imagine que isso não seja prioridade para a Fly.io, já que clientes grandes não usam esse tipo de workload. Fico curioso para saber quais hosts o pessoal usa para implantar apps SQLite em produção
No ano passado configurei um app Rails 8 novo na Fly; uso PG como armazenamento principal de dados, mas os bancos auxiliares da solid stack usam SQLite. Houve alguns probleminhas do lado do Rails relacionados às migrações do solid queue, mas não eram problemas da Fly. Também estou considerando migrar o PG principal para SQLite e, por enquanto, já estamos usando SQLite bem em algumas partes
Eu uso SQLite em um app de console em produção. O banco fica em um drive compartilhado por arquivos
Muito bom ver a Fly retomar o desenvolvimento do Litestream depois de 2 anos parado. Uso Litestream sempre e gosto demais. Na prática, sai muito mais barato do que o slogan publicitário de “alguns centavos por dia”. Quando usei replicação do Litestream para S3 em um app real de produção, o custo mensal ficou na faixa de 2 a 3 centavos de dólar (US$ 0,02 a US$ 0,03). Compartilho um relato relacionado
Acho incrível que em breve o Litestream vá suportar todos os destinos compatíveis com S3. Até agora tenho usado uma solução via SFTP justamente para não depender de serviços de object storage em nuvem hardcoded. Deixo meus agradecimentos aos desenvolvedores. PR e guia
Quero testar o Litestream em breve. Tenho curiosidade sobre benchmarks ou demos de quanto tempo a restauração realmente leva. No passado implementei meus próprios backups para S3 e, naquela época, com o Litestream levava 20 minutos para restaurar 1.000 linhas. Parecia bem pouco otimizado. Queria saber o quanto a velocidade de restauração melhorou hoje em dia
Gostaria de entender quais vantagens o Litestream tem em relação ao sqlite.org/rsync
O diferencial do Litestream é que ele não precisa de um “servidor” no outro lado; basta ter object storage. Isso pode acabar saindo mais barato
O Litestream permite Point In Time Recovery. Não existe apenas a réplica do momento atual; é possível restaurar para um snapshot de qualquer ponto no tempo
Uma observação interessante sobre LiteFS e Litestream: “a resposta do mercado é a resposta! Os usuários preferem mais o Litestream”. Sinceramente, voltei a focar nisso porque o Litestream é mais fácil de operar e entender
Compartilhando links relacionados ao Litestream Revamped e ao tópico no Hacker News
blog
tópico no HN
Estamos implantando aplicações internas em uma frota remota externa, mas a internet é instável, então é difícil montar um sistema de coleta de dados de forma adequada. Tenho curiosidade sobre como o Litestream lida com backups em ambientes instáveis como esse e se dá para consolidar vários backups em um banco central para consulta
Um pequeno alerta: certa vez, ao migrar um app de negócios legado para Azure, tive de lidar com uma arquitetura em que um servidor MSSQL local rodava junto com a aplicação, meio no padrão do Litestream. O app foi desenvolvido assumindo acesso local (latência abaixo de 1 ms), então havia consultas N+1 gravíssimas por toda parte. Isso tornou quase impossível mudar para outra arquitetura depois. Se você tem receio de usar uma hospedagem desse tipo e depois bater em limites de escala, eu não recomendaria. Dito isso, uma única máquina já consegue ir muito longe em termos de escala, então na prática talvez nem seja um grande problema
Hoje, com instâncias únicas suportando mais de 20 TB de RAM e centenas de núcleos, acho essa opção bem competitiva. Combinada com uma arquitetura de células por usuário/tenant, pode ser uma abordagem ainda mais eficiente
Também trabalhei no passado com um produto em que o servidor da aplicação e o banco ficavam no mesmo rack, com uma estrutura igualmente de baixa latência. Quando o produto deu certo e as consultas N+1 chegaram aos milhares, 1 ms rapidamente virava mais de 500 ms. A cada dois meses era o mesmo ritual de encontrar gargalos no NewRelic e corrigir. Como era um app Rails, problemas de N+1 apareciam com facilidade, mas também eram relativamente fáceis de consertar
Práticas ruins de consulta inevitavelmente vão causar problemas em algum momento. Não acho justo tratar isso como uma desvantagem específica dessa abordagem
Na verdade, no fim das contas, usar um serviço desses só expõe o quanto seu código tem problemas, então não vejo isso como um trade-off tão grande. A culpa é do código, não do serviço
Pergunta o que é N+1
Gosto muito do Litestream. É fácil de usar e nunca tive um crash. Recomendo usar como serviço de unidade do systemd. Não uso só como ferramenta de backup, mas também para espelhamento de banco de dados. Também estou no aguardo do futuro recurso de read-replica