Litestream v0.5.0

• Litestream v0.5.0 es una actualización que mejora significativamente la resiliencia de las aplicaciones basadas en SQLite
• Introduce el nuevo formato de archivo LTX, que permite una recuperación eficiente a un punto en el tiempo (PITR) y compresión de datos
• Elimina el concepto de generación (generation) entre múltiples instancias de Litestream para simplificar la administración y la operación
• Con soporte para JetStream y el cambio a un driver moderno de SQLite para Go, el desarrollo y la integración se vuelven más convenientes
• En el futuro se planea agregar funciones más potentes, como réplicas de lectura basadas en VFS

---

Resumen y actualizaciones principales

• Litestream es una herramienta de respaldo y recuperación para aplicaciones SQLite, de código abierto y con la característica de poder ejecutarse en cualquier lugar
• La recuperación ante fallas del servidor es sencilla, lo que brinda seguridad al construir aplicaciones full-stack basadas en SQLite
• La versión más reciente (v0.5.0) ofrece mejoras de velocidad y compatibilidad con Point-In-Time Recovery (PITR)

Evolución de LiteFS y Litestream

• Los principales proyectos relacionados con SQLite desarrollados por Ben Johnson de Fly.io son Litestream y LiteFS
• LiteFS busca la replicación en vivo a nivel de transacciones internas de la base de datos utilizando el sistema de archivos FUSE
• Sin embargo, la demanda del mercado se concentró en Litestream, que es más simple de operar, por lo que las lecciones técnicas obtenidas en LiteFS se reaplicaron en Litestream

Introducción del formato de archivo LTX

• Para resolver las limitaciones e ineficiencias del método anterior de respaldo de SQLite por páginas, se introdujo LTX (un formato basado en transacciones)

• LTX ofrece gestión de rangos de páginas según el orden de las transacciones y compactación de páginas duplicadas

  • Ejemplo: al aplicar varios archivos LTX desde el más reciente, solo se refleja la versión más nueva de las páginas duplicadas, lo que permite restaurar rápidamente el estado final de la base de datos
  • Mediante una estructura jerárquica de archivos, los archivos LTX se consolidan en intervalos de 30 segundos, 5 minutos y 1 hora para reducir drásticamente la cantidad de archivos necesarios para la restauración

• La velocidad de recuperación de datos está limitada únicamente por el rendimiento de I/O

Eliminación del concepto de generación (generation)

• Litestream puede ejecutarse y fallar como un proceso Unix común, y cuando se interrumpe su funcionamiento pueden producirse inconsistencias en la sincronización de datos
• Antes se había introducido un método de administración llamado generación (generation) para evitar conflictos entre múltiples instancias, pero
• con la transición a LTX, la recuperación basada en ID de transacción se volvió posible, haciendo innecesaria la compleja gestión por generaciones

Actualización a Litestream v0.5.0

• Debido al cambio profundo en el formato de archivo, no es posible restaurar directamente desde segmentos WAL de la versión v0.3.x
• La actualización es simple: ejecutar la nueva versión → generar nuevos archivos LTX, y los archivos WAL anteriores también se conservan tal como están
• También se mantiene la compatibilidad del archivo de configuración
• Cambio principal: ahora solo se permite un único destino de replicación por base de datos, una decisión tomada para facilitar el desarrollo y evitar conflictos de replicación
• Los comandos siguen siendo los mismos, pero el método de referencia cambió a uno basado en ID de transacción (TXID)

Otras mejoras

• La compresión por páginas y la adición de índices en la biblioteca del formato de archivo LTX permiten acceso selectivo a páginas dentro de archivos grandes y la expansión de funcionalidades
• En el futuro será posible implementar funciones adicionales, como consultas de datos en un punto específico en el tiempo
• Con la eliminación de la dependencia de CGO y el cambio del driver SQLite para Go a modernc.org/sqlite, hay ventajas para la compilación automática y los entornos de cross-compilation
• Se incluye soporte para el tipo de réplica JetStream, además de la actualización de los clientes de S3/Google Storage/Azure Blob Storage y compatibilidad con la nueva versión de la API de S3

Planes a futuro

• Está en desarrollo la función Litestream VFS para entornos de réplicas de lectura (target)
• Con esta función, será posible leer al instante solo las páginas necesarias desde S3 y crear réplicas rápidamente
• Ya existe un prototipo y su publicación está próxima

[GN⁺]

Opiniones de Hacker News

• La experiencia de desarrollo al desplegar apps con SQLite en Fly.io deja un poco que desear; intenté durante horas ejecutar una app de Rails en producción, pero me topé con varios problemas relacionados con la inicialización de la base de datos, las migraciones y el estado de escritura. La causa raíz era el eager loading de un gem que hice yo mismo, pero había varias capas de runners encima, así que fue difícil diagnosticarlo. Ojalá le dedicaran más esfuerzo a mejorar la DX, aunque imagino que para Fly.io no es prioridad porque sus clientes grandes no usan este tipo de carga de trabajo. Me da curiosidad saber qué hosts usan quienes ya han desplegado apps con SQLite en producción.

  • El año pasado configuré desde cero una app de Rails 8 en Fly. Uso PG como almacén principal de datos, pero las bases de datos auxiliares del solid stack usan SQLite. Hubo algunos problemas del lado de Rails relacionados con las migraciones de solid queue, pero no fueron problemas de Fly. Incluso estoy considerando migrar el PG principal a SQLite; por ahora ya lo estamos aprovechando bien en algunos casos.

  • Yo uso SQLite en una app de consola en producción. La base de datos está ubicada en una unidad compartida de archivos.

• Me da muchísimo gusto que Fly haya retomado el desarrollo de Litestream después de dos años de pausa. Lo uso siempre y estoy muy satisfecho. En la práctica cuesta mucho menos de lo que sugiere el eslogan de “unos cuantos centavos al día”; cuando usé replicación de Litestream hacia S3 en una app real de producción, el costo mensual efectivo fue de apenas 2 a 3 centavos de dólar (0.02 a 0.03 USD). Comparto un relato relacionado.

• Me parece genial que pronto Litestream vaya a soportar todos los destinos compatibles con s3. Hasta ahora uso una solución por SFTP porque prefiero no depender de servicios de almacenamiento de objetos en la nube hardcodeados. Gracias a los desarrolladores. Comparto el PR y la guía.

• Quiero probar Litestream pronto. Me gustaría ver benchmarks o demos sobre cuánto tarda realmente la restauración. Antes implementé mis propios respaldos en S3 y, en ese momento, restaurar 1,000 filas con Litestream tardaba hasta 20 minutos. Se sentía bastante poco optimizado. Me pregunto cuánto habrá mejorado hoy la velocidad de restauración.

• Me pregunto qué ventajas tiene Litestream frente a sqlite.org/rsync.

  • La diferencia de Litestream es que no necesitas un “servidor” en el otro extremo; basta con tener almacenamiento de objetos, y eso puede resultar más barato en costos.

  • Litestream permite recuperación a un punto en el tiempo (Point In Time Recovery). No solo tienes una réplica del estado actual, sino que puedes restaurar a un snapshot de cualquier momento.

• Una observación interesante sobre LiteFS y Litestream: “¡La respuesta del mercado lo dice todo! Los usuarios prefieren más Litestream”. Siendo sinceros, Litestream terminó recibiendo de nuevo el foco porque es más fácil de operar y más sencillo de entender.

  • A mí también me hace sentido. LiteFS requería ejecutar y montar un sistema de archivos personalizado basado en FUSE, mientras que Litestream solo necesita un binario de Go apuntando al archivo de base de datos SQLite y al archivo WAL asociado.

• Comparto enlaces sobre Litestream Revamped y la discusión en Hacker News
  blog
  discusión en HN

• Estamos desplegando aplicaciones internas en una flota remota externa, pero la conexión a internet es inestable, así que es difícil construir bien un sistema de recolección de datos. Me pregunto cómo maneja Litestream los respaldos en entornos tan inestables y si permite consolidar varios respaldos en una base de datos central para consultarlos.

• Una pequeña advertencia: una vez me tocó migrar una app de negocio legacy a Azure, con una arquitectura donde corrían la app y un servidor MSSQL local juntos, algo parecido al patrón de Litestream. La aplicación fue desarrollada asumiendo acceso local (latencia menor a 1 ms), así que estaba plagada de consultas N+1 por todos lados. Eso volvió casi imposible cambiar a otra arquitectura después. Si te preocupa usar este tipo de hosting y luego chocar con límites de escalabilidad, no lo recomendaría. Aun así, una sola máquina puede llegar bastante lejos, así que en la práctica quizá no sea un problema real.

  • Hoy en día una sola instancia puede soportar más de 20 TB de RAM y cientos de núcleos, así que me parece una opción perfectamente competitiva. Combinada con una arquitectura de celdas por usuario o por tenant, podría ser un enfoque todavía más eficiente.

  • Yo también trabajé antes en un producto donde el servidor de aplicaciones y la base de datos estaban en el mismo rack, con una estructura similar de baja latencia. Cuando ese producto tuvo éxito y las consultas N+1 crecieron a miles, ese 1 ms rápidamente se convertía en más de 500 ms. Cada dos meses nos tocaba volver a NewRelic para identificar cuellos de botella y corregirlos. Como era una app de Rails, los problemas N+1 aparecían con facilidad, aunque también eran relativamente fáciles de arreglar.

  • Las malas prácticas de consultas tarde o temprano siempre causan problemas. No creo que sea justo verlo como una desventaja de este enfoque en sí.

  • En realidad, al final usar este tipo de servicio solo deja en evidencia qué tan problemático es tu propio código, así que no me parece un gran trade-off. La culpa es del código, no del servicio.

  • Pregunta qué significa N+1.

• Me encanta Litestream. Es fácil de usar y nunca se me ha caído. Recomiendo usarlo como servicio con una unidad de systemd. No solo lo uso como herramienta de respaldo, también lo uso para hacer mirroring de bases de datos. Además, tengo muchas ganas de ver la futura funcionalidad de read replicas.