Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

SQLite puede hacer que el estado de un pipeline sobreviva a una caída y que una ejecución se reanude desde una transición registrada. Para lograrlo, guarda ejecuciones y pasos en tablas y confirma cada cambio de estado en una transacción. El modo WAL ayuda a gestionar lecturas y escrituras concurrentes, pero su checkpoint interno no registra el progreso del job ni convierte por sí solo una base en un historial completo de la aplicación.

Qué significa «checkpoint» en un pipeline

Hay dos mecanismos distintos que suelen llamarse checkpoint:

  • Checkpoint de aplicación: el punto de progreso que tu programa guarda, por ejemplo, que el paso 4 terminó y el siguiente paso pendiente es el 5.
  • Checkpoint WAL: una operación de SQLite que copia páginas válidas del archivo de write-ahead log (WAL) al archivo principal de la base de datos.

El primero permite reanudar el trabajo; el segundo es mantenimiento interno de la base. Un checkpoint WAL no crea un registro de los pasos del pipeline.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Qué protege SQLite y qué queda fuera

SQLite documenta transacciones serializables ACID: los cambios agrupados en una transacción se confirman como una unidad o no se aplican, incluso ante ciertos fallos del programa, del sistema operativo o pérdida de energía, bajo las condiciones de operación asumidas por SQLite. Esa propiedad permite guardar coherentemente el estado de un pipeline. SQLite: SQLite Is Transactional.

La garantía cubre la transacción de SQLite, no todos los efectos de una tarea. Si un paso envía un correo, cobra una tarjeta o actualiza un servicio remoto, una caída puede ocurrir después de que el efecto externo suceda pero antes de que la base registre el éxito. Para cerrar esa brecha, diseña el paso para ser idempotente, usa una clave de deduplicación que el destino respete o registra el trabajo pendiente mediante un patrón outbox. Esos mecanismos deben coordinarse con el sistema externo; SQLite no los aplica automáticamente.

La base también solo puede conservar aquello que la aplicación decide registrar. Para inspeccionar una ejecución y reconstruir su secuencia hacen falta identificadores de entradas, eventos de transición, referencias a artefactos y errores estructurados. Los logs pueden seguir siendo útiles para diagnóstico operativo, pero no deben ser el único lugar donde exista el estado necesario para reanudar.

Un esquema mínimo para registrar ejecuciones y pasos

Como punto de partida, separa la información de la ejecución de la de cada paso. Los nombres y columnas siguientes son una propuesta de diseño, no un esquema prescrito por SQLite:

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Rank #2
Tabla Campos útiles Para qué sirve
runs run_id estable; status; started_at; updated_at; referencia o huella de las entradas; current_step; error final, si lo hay Identificar la ejecución, consultar su estado general y decidir dónde reanudar.
steps run_id; step_id; número de intento; status; tiempos de inicio y fin; referencias a entradas y salidas; error estructurado Inspeccionar qué intentó hacer cada paso, sus resultados y reintentos.

Usa identificadores estables para una ejecución y sus pasos; no dependas del número de línea de un log. Guarda referencias a archivos u otros artefactos fuera de la base cuando sean grandes, y conserva suficiente identidad de las entradas para distinguir una repetición del mismo trabajo de una ejecución nueva. Un registro de transiciones puede complementar el estado actual si necesitas reconstruir cómo cambió.

Confirma las transiciones relacionadas juntas

Cuando un paso termina, actualiza su estado y el cursor o estado de recuperación de la ejecución en una sola transacción. Así evitas que la base indique que el paso concluyó mientras el cursor aún apunta a un punto incompatible, o viceversa.

  1. Abre una transacción.
  2. Registra el resultado del paso, las marcas de tiempo, la referencia a la salida y el error, si corresponde.
  3. Actualiza el estado de la ejecución y el siguiente punto de trabajo.
  4. Confirma la transacción; si falla, no avances el pipeline como si el cambio se hubiera guardado.

Mantén las transacciones cortas. No dejes una transacción de SQLite abierta mientras esperas a una API remota o se ejecuta un trabajo largo: los efectos externos no forman parte de ella y las transacciones prolongadas pueden complicar la concurrencia.

Cómo reanudar después de un fallo

  1. Abre la base con SQLite. Deja que SQLite gestione los archivos asociados al modo de journal configurado; no borres ni muevas manualmente el WAL.
  2. Busca la ejecución por su identificador estable. Lee su estado y el último paso cuyo resultado quedó confirmado.
  3. Determina si el paso incompleto puede repetirse. Si produce efectos externos, comprueba la clave de deduplicación o la idempotencia antes de ejecutarlo de nuevo.
  4. Reanuda desde el primer trabajo que no esté confirmado. Registra el nuevo intento y su transición en una transacción.
  5. Verifica las invariantes del dominio. Comprueba que las salidas y referencias necesarias existen y corresponden a las entradas de la ejecución.

Esta recuperación restaura el progreso descrito en la base, no necesariamente el contexto completo de un proceso que desapareció. Por eso conviene que cada paso pueda validar sus entradas y resultados y que los efectos irreversibles tengan un mecanismo propio de deduplicación o reconciliación.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Qué aporta WAL y cuáles son sus límites

En modo WAL, SQLite añade los cambios a un archivo separado; el commit se registra allí. Después, un checkpoint copia cambios del WAL al archivo principal. Mientras haya transacciones confirmadas que todavía no se hayan incorporado al archivo principal, el WAL forma parte del estado persistente de la base. No lo trates como un log desechable: separarlo del archivo principal puede perder transacciones confirmadas o dañar la base. SQLite: Write-Ahead Logging y SQLite: Database File Format.

SQLite ejecuta checkpoints automáticos; el umbral predeterminado documentado es de 1000 páginas. Un commit que alcance ese umbral puede activar uno. No equivale a un límite fijo en bytes: el tamaño de página de la base determina el volumen correspondiente. Además, el checkpoint puede no completarse si hay lectores que mantienen una instantánea anterior. El modo PASSIVE avanza tanto como puede sin interferir con lectores; otros modos pueden esperar o bloquear más.

WAL permite que lectores y escritor trabajen en paralelo, pero solo un escritor puede escribir en una base a la vez. Los procesos que acceden a esa base en modo WAL deben operar en el mismo equipo; la documentación de SQLite indica que no funciona como mecanismo de concurrencia entre máquinas a través de un sistema de archivos de red. Si el pipeline requiere escritores concurrentes, diseña la serialización de escrituras y mide la carga antes de elegir WAL.

Rollback journal o WAL

Aspecto Rollback journal WAL
Lecturas mientras hay escritura La documentación describe menos concurrencia entre lectores y escritor que en WAL. Lectores y escritor pueden avanzar en paralelo, sujetos a las reglas de WAL.
Escritores simultáneos Una escritura a la vez por base. Una escritura a la vez por base.
Uso entre equipos por sistema de archivos de red La restricción de mismo host citada por SQLite se refiere a WAL. No es compatible con clientes en máquinas distintas mediante un sistema de archivos de red.
Mantenimiento característico Usa rollback journal. Requiere gestionar checkpoints y tener en cuenta el WAL como parte del estado.

Para un pipeline de un solo host con lecturas concurrentes y escrituras serializadas, WAL puede ser conveniente. Si la simplicidad de operar con rollback journal encaja mejor con el patrón de acceso, no hay razón para activar WAL solo porque la aplicación tenga checkpoints de job: son mecanismos independientes.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Cómo hacer copias de seguridad sin separar la base del WAL

Una copia directa del archivo principal mientras la base está activa no es necesariamente una copia consistente. Si hay cambios confirmados en el WAL, copiar solo el archivo principal puede omitirlos; copiar archivos relacionados por separado y en momentos distintos también puede producir una combinación inválida.

Para una copia en línea, SQLite documenta dos opciones: la Online Backup API, que copia la base a otra base y produce una instantánea del origen según el momento en que comenzó la copia, y VACUUM INTO. La API mantiene bloqueos de lectura durante partes de la operación, no necesariamente durante toda su duración. Elige según la integración disponible y la forma de operar el respaldo; la documentación citada no establece un rendimiento comparativo para un pipeline concreto. SQLite: SQLite Backup API.

Prueba la restauración, no solo la creación del archivo

  1. Haz una copia mediante un método compatible con una base activa.
  2. Restaura la copia en una ubicación de prueba, sin sobrescribir la base de producción.
  3. Abre la base restaurada y consulta las ejecuciones y los pasos que esperas recuperar.
  4. Ejecuta las comprobaciones de integridad y las invariantes de tu aplicación que correspondan.
  5. Realiza una prueba controlada de reanudación, verificando que no repita efectos externos de forma indebida.

La comprobación de que el archivo puede abrirse no demuestra por sí sola que el pipeline pueda continuar correctamente. La prueba debe validar también las entradas, salidas y efectos externos que el flujo necesite.

Qué observar en operación

  • Transacciones: mantenlas breves y verifica que los cambios de estado relacionados se confirman juntos.
  • WAL: observa su tamaño y el patrón de lectores si el crecimiento o los checkpoints incompletos afectan la operación. Lectores que retienen instantáneas pueden impedir que un checkpoint avance por completo.
  • Checkpointing: checkpoints más frecuentes añaden trabajo de sincronización y búsqueda en disco; decide según la carga, no por la suposición de que cada confirmación debe vaciar el WAL.
  • Errores: guarda clase o código, mensaje útil, paso e intento, sin hacer depender la recuperación de texto libre de logs.
  • Retención: define cuánto tiempo necesitas conservar ejecuciones, transiciones y referencias a artefactos para auditoría y recuperación.
  • Copias: programa respaldos consistentes y verifica que el procedimiento incluya todos los cambios confirmados relevantes.

La página de SQLite sobre corrupción advierte de prácticas que pueden dañar archivos, entre ellas manipular archivos de base de datos de forma insegura. SQLite: How To Corrupt An SQLite Database File. Para trabajo forense, NIST publicó el 22 de febrero de 2021 un borrador de especificación para herramientas de recuperación de datos SQLite que contempla mostrar información recuperada y categorizar datos de WAL y rollback journal. Es un borrador, no una norma final ni una certificación de herramientas: NIST: SQLite Data Recovery Specification, Test Assertions and Test Cases, borrador.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.