From 97ff13cc836ad8dd0c394c2c50fcf4133e6b69bb Mon Sep 17 00:00:00 2001 From: chemavx Date: Fri, 31 Jul 2026 16:15:30 +0000 Subject: [PATCH] docs: leer la sqlite de n8n con cp se salta el WAL Un barrido hecho con cp dijo que un cambio recien escrito no estaba, media hora despues de escribirlo. La copia no tiene los ultimos commits y no da ningun error. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index d1b7792..9b47ad1 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -47,6 +47,24 @@ durante media hora. Regla: `kubectl -n n8n rollout restart deploy/n8n` y comprobar que el `startTime` del pod es POSTERIOR a la escritura, antes de dar por buena ninguna prueba. +## Leer `/data/n8n/database.sqlite` con `cp` enseña el pasado + +La BD va en **WAL**. Un `cp` del fichero principal deja fuera el `-wal`, así que +la copia no tiene los últimos commits y **no da ningún error**: enseña +tranquilamente valores viejos. El 2026-07-31 un barrido hecho así dijo que un +cambio recién escrito no estaba, media hora después de escribirlo. + +Para leer siempre en frío y completo: + +```python +src = sqlite3.connect("file:/data/n8n/database.sqlite?mode=ro", uri=True) +dst = sqlite3.connect(":memory:"); src.backup(dst) # o a un fichero +``` + +Vale igual para el `sqlite3` del host: apuntarlo al fichero directamente sí lee +el WAL, pero **cualquier copia previa con `cp`, no**. Es la misma razón por la +que las copias de seguridad usan `.backup` y no `cp`. + ## Antes de tocar una BD de un pod: desarmar ArgoCD Casi todo está bajo Applications con `automated{selfHeal,prune}`. Un